From: Sebastian Reichel <sre@kernel.org>
To: Rhyland Klein <rklein@nvidia.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] power_supply: fix return value of get_property
Date: Wed, 22 Jun 2016 16:37:17 +0200 [thread overview]
Message-ID: <20160622143716.GB16084@earth> (raw)
In-Reply-To: <2d2e4c90-472d-fa1a-6fbc-dfb99e80069d@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 4185 bytes --]
Hi,
On Tue, Jun 21, 2016 at 02:08:05PM -0400, Rhyland Klein wrote:
> On 6/16/2016 11:40 AM, Rhyland Klein wrote:
> > On 6/16/2016 4:43 AM, Krzysztof Kozlowski wrote:
> >> On 06/16/2016 12:13 AM, Rhyland Klein wrote:
> >>> power_supply_get_property() should ideally return -EAGAIN if it is
> >>> called while the power_supply is being registered. There was no way
> >>> previously to determine if use_cnt == 0 meant that the power_supply
> >>> wasn't fully registered yet, or if it had already been unregistered.
> >>>
> >>> Add a new boolean to the power_supply struct to simply show if
> >>> registration is completed. Lastly, modify the check in
> >>> power_supply_show_property() to also ignore -EAGAIN when so it
> >>> doesn't complain about not returning the property.
> >>>
> >>> Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> >>> ---
> >>> v2:
> >>> - Modify power_supply_show_property() to not complain if it
> >>> sees a return value of -EAGAIN after calling
> >>> power_supply_get_property().
> >>>
> >>> drivers/power/power_supply_core.c | 6 +++++-
> >>> drivers/power/power_supply_sysfs.c | 2 +-
> >>> include/linux/power_supply.h | 1 +
> >>> 3 files changed, 7 insertions(+), 2 deletions(-)
> >>
> >> I don't like it for two reasons:
> >> 1. There is still a short window when the information will be
> >> inaccurate. See comment below.
> >>
> >> 2. Although the code is not very complicated but it adds another field
> >> and some checks just for differentiating EAGAIN/ENODEV. It is
> >> unnecessary complexity.
> >>
> >>>
> >>> diff --git a/drivers/power/power_supply_core.c b/drivers/power/power_supply_core.c
> >>> index b13cd074c52a..a39a47672979 100644
> >>> --- a/drivers/power/power_supply_core.c
> >>> +++ b/drivers/power/power_supply_core.c
> >>> @@ -491,8 +491,11 @@ int power_supply_get_property(struct power_supply *psy,
> >>> enum power_supply_property psp,
> >>> union power_supply_propval *val)
> >>> {
> >>> - if (atomic_read(&psy->use_cnt) <= 0)
> >>> + if (atomic_read(&psy->use_cnt) <= 0) {
> >>> + if (!psy->initialized)
> >>> + return -EAGAIN;
> >>> return -ENODEV;
> >>> + }
> >>>
> >>> return psy->desc->get_property(psy, psp, val);
> >>> }
> >>> @@ -775,6 +778,7 @@ __power_supply_register(struct device *parent,
> >>> if (rc)
> >>> goto create_triggers_failed;
> >>>
> >>> + psy->initialized = true;
> >>
> >> If someone calls power_supply_get_property() here, then ENODEV will be
> >> returned which is wrong.
> >>
> >> The problem is not solved entirely... I am not convinced that introduced
> >> complexity is worth fixing it.
> >>
> >
> > Right now, without this patch, this causes the thermal function
> > "update_temperature" in:
> >
> > thermal_zone_device_register->
> > thermal_zone_device_update->
> > update_temperature
> > (->thermal_zone_get_temp() from the original stack)
> >
> > to print a warning as it sees ret != -EAGAIN. This causes a warning
> > "failed to read out thermal zone". I think the idea there is if anything
> > other than "try again" it complains. While this doesn't cause functional
> > problems, I do think avoid the warning is worth while.
> >
> > I think that there is an onus on the power_supply code to be accurate in
> > its return codes, and EAGAIN is the correct one we should be returning.
> > I don't see how someone would call power_supply_get_property, but I
> > agree there is the possibility that if someone did call there, that it
> > could return the wrong value.
> >
> > We could wrap the setting of initialized and use_cnt inside a mutex,
> > which should prevent anyone calling anything in between if we wanted to
> > completely plug that hole. I am not fond of the idea of adding a struct
> > member for such a small, specific case, but as we found before, I don't
> > think there is another way to differentiate otherwise.
> >
>
> Sebastian, do you have an opinion on this?
Instead of adding a mutex, just set "psy->initialized = true" after
increment of use_cnt. I'm fine with the patch otherwise.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-06-22 14:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 22:13 [PATCH v2] power_supply: fix return value of get_property Rhyland Klein
2016-06-16 8:43 ` Krzysztof Kozlowski
2016-06-16 15:40 ` Rhyland Klein
2016-06-21 18:08 ` Rhyland Klein
2016-06-22 14:37 ` Sebastian Reichel [this message]
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=20160622143716.GB16084@earth \
--to=sre@kernel.org \
--cc=dbaryshkov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=k.kozlowski@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rklein@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox