[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101023154355.GB8994@sucs.org>
Date: Sat, 23 Oct 2010 16:43:56 +0100
From: Sitsofe Wheeler <sitsofe@...oo.com>
To: Richard Hughes <hughsient@...il.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Matthew Garrett <mjg59@...f.ucam.org>,
Len Brown <lenb@...nel.org>, Zhang Rui <rui.zhang@...el.com>,
David Zeuthen <davidz@...hat.com>,
Richard Hughes <richard@...hsie.com>,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI / Battery: Return -ENODATA for unknown values in
get_property()
On Fri, Oct 22, 2010 at 01:31:28PM +0100, Richard Hughes wrote:
> On 21 October 2010 17:54, Sitsofe Wheeler <sitsofe@...oo.com> wrote:
> > I guess there are a whole bunch of other attributes that could
> > theoretically be -1 and shouldn't be used if they return it...
>
> I think checking for <0 is probably a good idea, and I'm a little
> surprised we don't do this already. Patch welcome, if this is what you
> decide to do.
I can only guess that at some point in upower's past negative values for
current_rate were found to be valid so upower took the route of making
them absolute to work around that behaviour. If so, it would be good to
know whether there are still devices in this category running a stock
kernel.
If the latest patch to return -ENODEV goes in, then there's the
possibility for upower to detect the unknown state and report unknown
back to its users. Would the existing interfaces support outputting
unknown instead of a number? If not (and there are no plans to) I
suspect the best thing to do is to remove the test for 0xffff and
continue to return 0.
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists