Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1324826ybe; Fri, 13 Sep 2019 14:48:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqzCzE0KbM9SA98e+Lof736rpjbRhUQKepnP/tNBUj6X1lSPX2+GcprOAMEYG/VdFAi60DTI X-Received: by 2002:a50:f787:: with SMTP id h7mr17752878edn.101.1568411304329; Fri, 13 Sep 2019 14:48:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568411304; cv=none; d=google.com; s=arc-20160816; b=fqm1iK0/coxUQfSjARmv29BsRPvZbH27rBxt/SMNYw/1WojGCbggWgB9ZYFInXz3fd vPhrDeLoNWfZSBUhLrlyKByPUlpFmVSkuSwGQI3b3e+Rht+nAvVP1fNttYZFz3XP+Po7 zv5wCQNDG13WgjWBWhJJX2vyQsDX9a0Cr0B8vBjdsHby7365P7RT3aIJUR8NJ3E4M1rC 6PWrc4UyGh3IWmZJ8xOJJNSxmrTS9vTnT3K6LL54PG8SvIrSOhaCz2rAIm7+VXXSKYVx NEOTfwTLC3vVhyCiNpu0lBxi37HaWyKrHkLE7knOsv2UPPOhWdr0aDRtMSeFfx/eO77d esDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :dkim-signature; bh=I5KYFSSfB4WK2rrNM9kVDaLOfXvwrxisel5lvyCFyjY=; b=j47v+CmsYTtceYlx15xSCvUGUEnUhh0BVh9LIxItGe5U1ENGf2MpHf/rcuHksbgogp xf2WwsHBqv0IUmYs01BL58ZaF7wxJj2H7NzcVG/Tda9dtpbiXv18cjUGcckTRWdAXG7g WSg/9XKepPnljybLGEh5xzhuwhYPYEr2aIgm4NEL16vKNRNRcgqSWq9c7EVWXhOVkeiD PdWL53KDvaFW5zCDnHU6g+9zn52/mpQvFHH1fLVkZvud7TUMLgSQu7IHHHibUGoznKgu BBLmTzzzln7PQCMglZJJLx1qn3BmWHeZ2Ko80Y0LlCpIr/baKcQLfCqhGpbNpvxJ9vV4 corQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pedrovanzella.com header.s=fm1 header.b=dBO2ZaWc; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=XfAkFq8q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si8170876edq.21.2019.09.13.14.48.00; Fri, 13 Sep 2019 14:48:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@pedrovanzella.com header.s=fm1 header.b=dBO2ZaWc; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=XfAkFq8q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731353AbfIMVpu (ORCPT + 99 others); Fri, 13 Sep 2019 17:45:50 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42477 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730990AbfIMVpu (ORCPT ); Fri, 13 Sep 2019 17:45:50 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C72AB21C39; Fri, 13 Sep 2019 17:45:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 13 Sep 2019 17:45:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pedrovanzella.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=fm1; bh=I5KYFSSfB4WK2rrNM9kVDaLOfX vwrxisel5lvyCFyjY=; b=dBO2ZaWcH4b2o4/H5w7CFZxsfhZngszuT1tRyHIp1g +Tgo6BqwYStcsXS0NUmuNhUrJxBNMHW8kzk5W5SrGeyzWNcTNtWHymmLi0goDVtN NqCXvkroqxFDgfUvWS9FfdCtIhrrzI/yGbJ28ZUIzHlhFV8aNUQh8gJ8nuQzhAWD NI+o7i95XVG0oOToyP42DzLq12fdjq5+mRmDMZLq8SE4v/TmmQPrvTBYZhwx8BWU 1JH/2wHsXGO22dTNOwQsHEC7Zpy2sbaQ0dtRjZ3gQsfQgxqMWwEWiSh0vpA5NJqA 2Sfl2597+lVLriggCt4uiHTd62Xh5w2kItyBbOZOoA6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=I5KYFSSfB4WK2rrNM9kVDaLOfXvwrxisel5lvyCFy jY=; b=XfAkFq8qCqzv2od14xY8ZjZJpEzooNcMQZ/NfQ6rHNaxBb6kia1IsYwDi bT9pXG4g+Enj05qQs+hG3JfWeaauhMeS7g/qAu5+SMj8v4i78VRxvvYwgjqDHHHi MmzqTGSQ6zBmWaHpjdnHMzQtUV9jolC4BmmXwuTmxTINVBFY8QBBpWhNN4kP+jqq QdIh+tqL1CxAt+mrh8YTdDJL6Cc2c7uVclJwRCL9gsPDNVT0ykZw+NLerNT8xdxC pP2A6QFWZIboFVVMxDCm4/Ph1FK8eFeuLP7lu6m+6t2kV8cS65/vAc79BK1LFSZR GQV6D4Z5z6kLSpPkEnh7hwFOyE/XQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtdejgdduieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgvughr ohcugggrnhiivghllhgruceophgvughrohesphgvughrohhvrghniigvlhhlrgdrtghomh eqnecukfhppedukeegrddugeehrddufedtrdegjeenucfrrghrrghmpehmrghilhhfrhho mhepphgvughrohesphgvughrohhvrghniigvlhhlrgdrtghomhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: from [192.168.2.43] (toroon020aw-lp130-01-184-145-130-47.dsl.bell.ca [184.145.130.47]) by mail.messagingengine.com (Postfix) with ESMTPA id E618280064; Fri, 13 Sep 2019 17:45:46 -0400 (EDT) Subject: Re: [PATCH v5] hid-logitech-hidpp: read battery voltage from newer devices To: =?UTF-8?Q?Filipe_La=c3=adns?= , linux-input@vger.kernel.org Cc: Jiri Kosina , Benjamin Tissoires , linux-kernel@vger.kernel.org References: <20190831175659.7404-1-pedro@pedrovanzella.com> <80785df1c804796a01bbfbae4b2aeda66f30d7c5.camel@archlinux.org> From: Pedro Vanzella Message-ID: Date: Fri, 13 Sep 2019 17:45:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <80785df1c804796a01bbfbae4b2aeda66f30d7c5.camel@archlinux.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/9/19 8:00 AM, Filipe Laíns wrote: > On Sat, 2019-08-31 at 13:56 -0400, Pedro Vanzella wrote: >> +static int hidpp20_battery_map_status_voltage(u8 data[3], int >> *voltage) >> +{ >> + int status; >> + >> + switch (data[2]) { >> + case 0x00: /* discharging */ >> + status = POWER_SUPPLY_STATUS_DISCHARGING; >> + break; >> + case 0x10: /* wireless charging */ >> + case 0x80: /* charging */ >> + status = POWER_SUPPLY_STATUS_CHARGING; >> + break; >> + case 0x81: /* fully charged */ >> + status = POWER_SUPPLY_STATUS_FULL; >> + break; >> + default: >> + status = POWER_SUPPLY_STATUS_NOT_CHARGING; >> + } >> + >> + *voltage = get_unaligned_be16(data); >> + >> + return status; >> +} > > Here's the missing specification: > > +--------+-------------------------------------------------------------------------+ > | byte | 2 | > +--------+--------------+------------+------------+----------+----------+----------+ > | bit | 0..2 | 3 | 4 | 5 | 6 | 7 | > +--------+--------------+------------+------------+----------+----------+----------+ > | buffer | chargeStatus | fastCharge | slowCharge | critical | (unused) | extPower | > +--------+--------------+------------+------------+----------+----------+----------+ > Table 1 - battery voltage (0x1001), getBatteryInfo() (ASE 0), 3rd byte > > +-------+--------------------------------------+ > | value | meaning | > +-------+--------------------------------------+ > | 0 | Charging | > +-------+--------------------------------------+ > | 1 | End of charge (100% charged) | > +-------+--------------------------------------+ > | 2 | Charge stopped (any "normal" reason) | > +-------+--------------------------------------+ > | 7 | Hardware error | > +-------+--------------------------------------+ > Table 2 - chargeStatus value > > I know this is already on the 5th revision but could you please change > hidpp20_battery_map_status_voltage() to properly handle the 3rd byte? > Also, if you could make sure those values are properly exported via > sysfs it would be great! We will need them for proper upower support. Sure thing. I'll have a new patch in a few days. Thanks for figuring that stuff out, by the way. > > Sorry for not saying this in my first review. Since then I have done > some testing and I discovered that if we want to get accurate upower > support we will need the values exposed by the 3rd byte to be > exported properly. > > I am not sure about the endianness of chargeStatus but you can find > that easily. > > Thank you! > Filipe Laíns >