Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD30EC6FA9D for ; Wed, 1 Mar 2023 18:51:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229775AbjCASv0 (ORCPT ); Wed, 1 Mar 2023 13:51:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230152AbjCASvT (ORCPT ); Wed, 1 Mar 2023 13:51:19 -0500 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E01494DE39 for ; Wed, 1 Mar 2023 10:50:55 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id s26so57758172edw.11 for ; Wed, 01 Mar 2023 10:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1677696653; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0iUZAnJK6gz4oERofIoMWErNXIlGl6/+yG6iePuXC0I=; b=OEzv3ztlUkaTFHVQhmuj1cOuU7W508fgRqtyIaeMiq6tyMjmoSbM8qYK+ptLJ2shCv hG78D5aijZL8I3UjKY7oy0rMyV1qitjUHubHIKTaUvrcevzM7AkNXIn7fOPtIGoRaBK2 3H2JyQ1M9DI/AK08U7Q63YyO5mBx2kDhCccp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677696653; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0iUZAnJK6gz4oERofIoMWErNXIlGl6/+yG6iePuXC0I=; b=y2wfsapWyCBuYO1YqN4UXZkm7uNnA1/QDTlJioMy6d+W5AEISMszCsWJ1SVbD4Y9wP WExCFC8+d5AAWkVS43cLdonx7B7DMDzvRia3OJgFgkPxddb07F60QXtx2UpMgGPWXi8k VXm0yYSt6f+LPLASOEaC2cHB+OcwQ3WNFwMh8tccZn31pL0KrZINChz3L9HAyLl1UCsE t8PsRjbUBsTwLdpU6ADsQyMnuPrLEWDqSAD5jHjhL6T7M5ZP+qL7tF/jCynadpydgrgj k1xcyGh0kV1/ARoRFRxGRfBaYWso3y0jFBQvnpKC5Wt5MmP3q0ZrILT6RrNngto7zx7E IqSQ== X-Gm-Message-State: AO0yUKUJmanZzWoa+S9mt4wLQiNU/Dec3DVkBS84oYzdJZFyjtsnYsDH BUdhB6oPl7Wk3FAPZNYpxuqrWDs5KZe/aMdtVtHmWw== X-Google-Smtp-Source: AK7set8fMJF9D2ApuA/L7HaJSf1ACkj77LfC7YuAcv3qy435V2sZ47k1riCpLpOgvvj8YvO/xvoHRQ== X-Received: by 2002:a17:907:3e24:b0:8aa:1f89:122e with SMTP id hp36-20020a1709073e2400b008aa1f89122emr10687647ejc.39.1677696653057; Wed, 01 Mar 2023 10:50:53 -0800 (PST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com. [209.85.208.47]) by smtp.gmail.com with ESMTPSA id le13-20020a170907170d00b008c44438734csm6140862ejc.113.2023.03.01.10.50.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Mar 2023 10:50:52 -0800 (PST) Received: by mail-ed1-f47.google.com with SMTP id o12so57839885edb.9 for ; Wed, 01 Mar 2023 10:50:52 -0800 (PST) X-Received: by 2002:a17:906:c08c:b0:8f1:4cc5:f14c with SMTP id f12-20020a170906c08c00b008f14cc5f14cmr3831646ejz.0.1677696652007; Wed, 01 Mar 2023 10:50:52 -0800 (PST) MIME-Version: 1.0 References: <20230214132052.1556699-1-arnd@kernel.org> In-Reply-To: From: Linus Torvalds Date: Wed, 1 Mar 2023 10:50:33 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] power: supply: qcom_battmgr: remove bogus do_div() To: Nathan Chancellor Cc: Andy Gross , Bjorn Andersson , Sebastian Reichel , Arnd Bergmann , Konrad Dybcio , Neil Armstrong , linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 1, 2023 at 10:16=E2=80=AFAM Nathan Chancellor wrote: > > Would you be able to take this patch directly? It seems obviously > correctTM, has an ack from Sebastian [1], and without it, 32-bit > allmodconfig builds are broken [2] (the other warning in that log has a > fix on the way to you soon). Ok, I've taken it directly. However, the whole "seems obviously correct" is true in the sense that it now doesn't complain (and doesn't overwrite an "int" with a 64-bit value. The actual code still looks odd. Is that return value for BATT_CAPACITY truly in that odd "hundredths of percent" format, where dividing it by 100 gives you whole percent? Because "hundredths of percent" strikes me as a very odd interface. Even for some firmware interface. I realize that anything is possible with strange firmware, but still... Linus