From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73818C433E9 for ; Mon, 4 Jan 2021 11:21:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3EC8D21D93 for ; Mon, 4 Jan 2021 11:21:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726313AbhADLVS (ORCPT ); Mon, 4 Jan 2021 06:21:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726306AbhADLVS (ORCPT ); Mon, 4 Jan 2021 06:21:18 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE704C061796 for ; Mon, 4 Jan 2021 03:20:37 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id y24so26914545edt.10 for ; Mon, 04 Jan 2021 03:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MZWKWB6DR6hNDrsfU5p9DwYo2p/txd/B82NQ7fAKCkU=; b=nl9r27QNZY4Nj976rgvuCPiFY8wmes/BZl9umicY7cdV5Fxo65af2BrZmdHzWXIobt oOIWzDwmZlzJ+VLUWsqIfQpqc6bGiZgUeqKQz+cSyvdruBb3tLxfz2mX5cjngPL00izA jKU+EP+gmt7AU7mKPsjiYsvEGXM4g6KcOpVKz5FfcnjWpqdCKjcXmU5XvQhBC59tGcVA sFXHAd1mGsSXug2gdh18mC7rN85u6D5jxHebdmrMg5cJ4ZQCom4WaIouYIyB+huraAHb mnknX2v4ZX85PGB6N3r8QKcP0KJItnyVdKr8S4V4Kf6GeqLKrYMRGdE+L8A9grpgXzQe qyyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MZWKWB6DR6hNDrsfU5p9DwYo2p/txd/B82NQ7fAKCkU=; b=tsqBX8meygO1VN8HxgWmCU1960jPZuDVcTFs58rXHAxJvRAuCXYQpfWBOVorHjeGzZ eLuYM2XCnVlxmuV52obYCFa3dG5RaUC3UNmRObs1yg2hcaGHIcWHnvqedPma2qye8K4e tyzZ2/YXYzKuXg9xc+QMfBN4g65aB9XcmtIAB7KlDnnO/7uGVqtURL9JG/PvFKf75sRc tFM8xhPl7KjJI4euAYJbOqALCEqTVgDEVbPqOqb0fUiz9lWKvbjuVhpN5NafQVU9boWn CwmLpW096Gu6mBNq5KsOKXdp3xLLSzLG64bjLF8vwRBtAo76r0y4+nUPIr5l+Ouwghf/ 5REA== X-Gm-Message-State: AOAM533rXjsaT/civ4Ft73Moqe4KSHNEQOpIt0kCYITZDfCRK+UShghx HsbUwPnj43eSOB0mQ3HD+u70pg== X-Google-Smtp-Source: ABdhPJwHI1lN3jR5DnkDpXruXetK/kDTL1pCTJK1usrE58eGVznR+xTruuuJBkNz+y3TDbBeob5Xaw== X-Received: by 2002:a50:e84d:: with SMTP id k13mr68908071edn.154.1609759236390; Mon, 04 Jan 2021 03:20:36 -0800 (PST) Received: from [192.168.0.41] (lns-bzn-59-82-252-129-8.adsl.proxad.net. [82.252.129.8]) by smtp.googlemail.com with ESMTPSA id h16sm23360677eji.110.2021.01.04.03.20.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jan 2021 03:20:35 -0800 (PST) Subject: Re: [PATCH] powercap/drivers/dtpm: Fix __udivdi3 and __aeabi_uldivmod unresolved symbols To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Linux PM list , ACPI Devel Maling List , kernel test robot , "Rafael J. Wysocki" , open list References: <20201230153744.15612-1-daniel.lezcano@linaro.org> From: Daniel Lezcano Message-ID: Date: Mon, 4 Jan 2021 12:20:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi Geert, On 04/01/2021 09:18, Geert Uytterhoeven wrote: > Hi Daniel, > > On Wed, Dec 30, 2020 at 4:39 PM Daniel Lezcano > wrote: >> 32 bits architectures do not support u64 division, so the macro >> DIV_ROUND_CLOSEST is not adequate as the compiler will replace the >> call to an unexisting function for the platform, leading to an >> unresolved symbols. >> >> Fix this by using the compatible macros: >> >> DIV64_U64_ROUND_CLOSEST and DIV_ROUND_CLOSEST_ULL. >> >> Reported-by: kernel test robot >> Signed-off-by: Daniel Lezcano > > Thanks for your patch! > >> --- a/drivers/powercap/dtpm.c >> +++ b/drivers/powercap/dtpm.c >> @@ -99,8 +99,8 @@ static void __dtpm_rebalance_weight(struct dtpm *dtpm) >> pr_debug("Setting weight '%d' for '%s'\n", >> child->weight, child->zone.name); >> >> - child->weight = DIV_ROUND_CLOSEST(child->power_max * 1024, >> - dtpm->power_max); >> + child->weight = DIV64_U64_ROUND_CLOSEST( >> + child->power_max * 1024, dtpm->power_max); > > Note that 64-by-64 divisions are expensive on 32-bit platforms. > > Does dtpm.power_max need to be u64? The dtpm is based on the powercap framework which deals with microwatts and the functions are expecting u64 values. The division here happens when there is an update of the dtpm tree which occurs rarely (at boot time or hotplug). As the power model is in the vast majority on 64b platforms, the effort to optimize to u32 sounds not worth, especially that the 32b platforms supporting the energy model are now obsolete. > The (lack of) documentation for the dtpm structure does not say what is > being stored there. > > Gr{oetje,eeting}s, > > Geert > -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog