From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: dmaengine <dmaengine@vger.kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Sinan Kaya <okaya@codeaurora.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Vinod Koul <vinod.koul@intel.com>
Subject: [v3,1/5] ACPI / bus: Return error code from __acpi_match_device() in one case
Date: Thu, 08 Feb 2018 17:59:08 +0200 [thread overview]
Message-ID: <1518105548.22495.201.camel@linux.intel.com> (raw)
On Thu, 2018-02-08 at 16:48 +0100, Rafael J. Wysocki wrote:
> On Thu, Feb 8, 2018 at 4:44 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, 2018-02-08 at 16:14 +0100, Rafael J. Wysocki wrote:
> > >
> >
> > > Also the return value here means "success", so why is an error the
> > > right choice?
> >
> > Because we need to return something which is not NULL. Naturally
> > feels
> > the error code, esp. ENODATA, is quite suitable. We indeed have no
> > data
> > in this case, and it's not a NULL case (not found / not match) — we
> > have
> > a match.
>
> But this is an error code that means "success". May I call it rather
> confusing?
This function AFAICS does two things at once:
- matches device against ID
- returns matched ID entry in the table
Return value combines those two into actually ternary option:
- no match
- match with ID
- match without ID
> > > Overall, this really looks like a preparation for a future patch,
> > > so
> > > why not just say that straight away in the changelog?
> >
> > It's not _just_ a preparation, it mitigates the trick used in
> > mentioned
> > by Fixes tag commit.
> >
> > I would rather update comment here, and add explanation to the
> > commit
> > message to be sure it covers tricks mitigation and preparation
> > purposes.
>
> This is not mitigation, sorry. It just replaces one possibly
> confusing thing with another.
I would agree here...
> The code as is works as I said and this patch doesn't make it any
> better as far as I'm concerned.
...but not here. Instead of returning pointer to *something* (from
caller point of view), we explicitly tell caller what of the above
happened. We don't rely on the organization of ID table or its life
time (though it's forever).
I can say that is *slightly* better. But agree that is not cleanest
solution I can come up with.
I'm all ears on other possibilities how to get rid of that trick.
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: dmaengine <dmaengine@vger.kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Sinan Kaya <okaya@codeaurora.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Vinod Koul <vinod.koul@intel.com>
Subject: Re: [PATCH v3 1/5] ACPI / bus: Return error code from __acpi_match_device() in one case
Date: Thu, 08 Feb 2018 17:59:08 +0200 [thread overview]
Message-ID: <1518105548.22495.201.camel@linux.intel.com> (raw)
In-Reply-To: <CAJZ5v0gFM+g0TbwjQ4KzVFop60JgSDA9UuM-zuy=+HdDcG8sQQ@mail.gmail.com>
On Thu, 2018-02-08 at 16:48 +0100, Rafael J. Wysocki wrote:
> On Thu, Feb 8, 2018 at 4:44 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, 2018-02-08 at 16:14 +0100, Rafael J. Wysocki wrote:
> > >
> >
> > > Also the return value here means "success", so why is an error the
> > > right choice?
> >
> > Because we need to return something which is not NULL. Naturally
> > feels
> > the error code, esp. ENODATA, is quite suitable. We indeed have no
> > data
> > in this case, and it's not a NULL case (not found / not match) — we
> > have
> > a match.
>
> But this is an error code that means "success". May I call it rather
> confusing?
This function AFAICS does two things at once:
- matches device against ID
- returns matched ID entry in the table
Return value combines those two into actually ternary option:
- no match
- match with ID
- match without ID
> > > Overall, this really looks like a preparation for a future patch,
> > > so
> > > why not just say that straight away in the changelog?
> >
> > It's not _just_ a preparation, it mitigates the trick used in
> > mentioned
> > by Fixes tag commit.
> >
> > I would rather update comment here, and add explanation to the
> > commit
> > message to be sure it covers tricks mitigation and preparation
> > purposes.
>
> This is not mitigation, sorry. It just replaces one possibly
> confusing thing with another.
I would agree here...
> The code as is works as I said and this patch doesn't make it any
> better as far as I'm concerned.
...but not here. Instead of returning pointer to *something* (from
caller point of view), we explicitly tell caller what of the above
happened. We don't rely on the organization of ID table or its life
time (though it's forever).
I can say that is *slightly* better. But agree that is not cleanest
solution I can come up with.
I'm all ears on other possibilities how to get rid of that trick.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next reply other threads:[~2018-02-08 15:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 15:59 Andy Shevchenko [this message]
2018-02-08 15:59 ` [PATCH v3 1/5] ACPI / bus: Return error code from __acpi_match_device() in one case Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2018-02-08 17:06 [v3,2/5] ACPI / bus: Do not traverse through non-existed device table Rafael J. Wysocki
2018-02-08 17:06 ` [PATCH v3 2/5] " Rafael J. Wysocki
2018-02-08 16:53 [v3,2/5] " Andy Shevchenko
2018-02-08 16:53 ` [PATCH v3 2/5] " Andy Shevchenko
2018-02-08 16:13 [v3,2/5] " Andy Shevchenko
2018-02-08 16:13 ` [PATCH v3 2/5] " Andy Shevchenko
2018-02-08 16:05 [v3,1/5] ACPI / bus: Return error code from __acpi_match_device() in one case Rafael J. Wysocki
2018-02-08 16:05 ` [PATCH v3 1/5] " Rafael J. Wysocki
2018-02-08 16:01 [v3,2/5] ACPI / bus: Do not traverse through non-existed device table Rafael J. Wysocki
2018-02-08 16:01 ` [PATCH v3 2/5] " Rafael J. Wysocki
2018-02-08 15:59 [v3,2/5] " Rafael J. Wysocki
2018-02-08 15:59 ` [PATCH v3 2/5] " Rafael J. Wysocki
2018-02-08 15:48 [v3,1/5] ACPI / bus: Return error code from __acpi_match_device() in one case Rafael J. Wysocki
2018-02-08 15:48 ` [PATCH v3 1/5] " Rafael J. Wysocki
2018-02-08 15:45 [v3,1/5] " Rafael J. Wysocki
2018-02-08 15:45 ` [PATCH v3 1/5] " Rafael J. Wysocki
2018-02-08 15:44 [v3,1/5] " Andy Shevchenko
2018-02-08 15:44 ` [PATCH v3 1/5] " Andy Shevchenko
2018-02-08 15:14 [v3,1/5] " Rafael J. Wysocki
2018-02-08 15:14 ` [PATCH v3 1/5] " Rafael J. Wysocki
2018-02-07 14:56 [v3,5/5] device property: Constify device_get_match_data() Andy Shevchenko
2018-02-07 14:56 ` [PATCH v3 5/5] " Andy Shevchenko
2018-02-07 14:56 [v3,4/5] ACPI / bus: Rename acpi_get_match_data() to acpi_device_get_match_data() Andy Shevchenko
2018-02-07 14:56 ` [PATCH v3 4/5] " Andy Shevchenko
2018-02-07 14:56 [v3,3/5] ACPI / bus: Remove checks in acpi_get_match_data() Andy Shevchenko
2018-02-07 14:56 ` [PATCH v3 3/5] " Andy Shevchenko
2018-02-07 14:56 [v3,2/5] ACPI / bus: Do not traverse through non-existed device table Andy Shevchenko
2018-02-07 14:56 ` [PATCH v3 2/5] " Andy Shevchenko
2018-02-07 14:56 [v3,1/5] ACPI / bus: Return error code from __acpi_match_device() in one case Andy Shevchenko
2018-02-07 14:56 ` [PATCH v3 1/5] " Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1518105548.22495.201.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sakari.ailus@linux.intel.com \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.