From: Henrique de Moraes Holschuh Subject: Re: [PATCH] ACPI / Battery: Return -ENODATA for unknown values in get_property() (was: Re: Returning ACPI_BATTERY ...) Date: Sun, 17 Oct 2010 03:19:53 -0200 Message-ID: <20101017051953.GA3430@khazad-dum.debian.net> References: <20101016141321.GA11054@sucs.org> <201010170105.33274.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:37778 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751400Ab0JQFT5 (ORCPT ); Sun, 17 Oct 2010 01:19:57 -0400 Content-Disposition: inline In-Reply-To: <201010170105.33274.rjw@sisk.pl> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: "Rafael J. Wysocki" Cc: Sitsofe Wheeler , Matthew Garrett , Len Brown , Zhang Rui , David Zeuthen , Richard Hughes , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org On Sun, 17 Oct 2010, Rafael J. Wysocki wrote: > In fact, the driver is supposed to return -ENODATA in that case, which will > result in the read from /sys/class/power_supply/BAT0/current_now fail (I guess > upower should be able to cope with that). ENODATA? Shouldn't it be ENXIO? There is no non-blocking data stream involved in a sysfs attribute. Of course, the RIGHT thing would be to not expose in sysfs attributes that are unsupported by the firmware/hardware in the first place, but that's easier said than done. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh