Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1632079rda; Mon, 23 Oct 2023 20:34:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFJJYA6L9SGzrZ1+3DANsI98mG+eQ4lmDefabmDmW3O9u/o6VTjcmcQr3uVr6gqp24Jz0CP X-Received: by 2002:a05:6a20:100f:b0:152:e902:8aa with SMTP id gs15-20020a056a20100f00b00152e90208aamr1322205pzc.34.1698118468611; Mon, 23 Oct 2023 20:34:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698118468; cv=none; d=google.com; s=arc-20160816; b=WB0oQeoLznByf/eb0gJ/YzsCGW1B9uFoBgJY2lapSCe1OYdEztzl+oKwuMt/jyZcjy h2O6bZGG6nFqtz8y6QpVFpvmsrsoj1CoKk1nV6oYCZwuUukrIQGr34k6HLSegTlXOhM8 K6DF+QHQGGNxAIrlYL6rtUlz2fSNiirVAmw9oFHnk64q5c7dUu4wAZg98b8j6Vra8Kwd 6mOAnhjJYXswt0uhJRnQUw1tzwC4Sd8sPob97bHDAvxQ8HzYWCcgNy9osG2kskOd//9f m16ues2AAYtL3RfivUKkY7nAstE/oKNUZvfBmOD3Z8b2qW7NJ+dKGfdjdwYTpxkm5ne7 AhWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:date:to:cc:from:subject:references :in-reply-to:content-transfer-encoding:mime-version:message-id :dkim-signature; bh=agFDAlUaRnKpI3gp/xyMD3qBmB6BCWZJaSy4GE08bms=; fh=ZBz6Qf1LDaNBWIk+8E5LzKv+pwk9rlK3VtL9omhn69k=; b=wC+80YfwTube8QOmvidesp3B/9Ui4LHqss0u3xZGgGkuDPrvBXNBw/GGn20PnbJfrq 29dtOIzMeTtDLB2TGal7ZhK7fzMVRwv+0+jT9VzvqgBHH53thumSaCtFKUII1BBcRqfz 3XLxPbogAJtua5gDssg0xzQs3/ZAc/kudYHqeAoTN3y7B9zNUJPklV+s35uePEZ1HjWs DlmuTvskpbs0in46b890nby0Z7054AhUjJjGHHRjDWxsU/dvmwKKs84WzZHnt6x7sziy hzU81kge7sRX/SfbNAJDQ+I6MAlINg1ZfRtuxO7moAqLm6tDiyKqh6TI65lAsRvYulO9 J3KA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=r7OVIIu9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id f20-20020a17090ac29400b002791b907f0csi10052742pjt.121.2023.10.23.20.34.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 20:34:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=r7OVIIu9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 3CD6580B993F; Mon, 23 Oct 2023 20:34:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232011AbjJXDeT (ORCPT + 99 others); Mon, 23 Oct 2023 23:34:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231254AbjJXDeS (ORCPT ); Mon, 23 Oct 2023 23:34:18 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98EBC90; Mon, 23 Oct 2023 20:34:16 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19C5BC433C7; Tue, 24 Oct 2023 03:34:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698118456; bh=AUfGK4LRDTP1ffobLLgoDerJIC0MFT8bIHsXjO28BxI=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=r7OVIIu9siFAC7IXMJuDD4peZpTdWBfveK3RFkdN7IuTFtZgCKswhbdm7bl0ZQmfz 9cm5+/8XPvC54PytUqB6eWS3pqgdPhvpiKTTlR0eN+9CXijSSQiR64eneyYB+IMqs/ 70OtqUeLTjsGK5to3bp1MLpT1wo4Wp2inslcej4RGFtWqdIRenFdP5ZMzXRyKCyFeC pgVfCVfl/xYxvyJGI/nM6cuEWI4O5FO1jdfe2lwMJHsT5weIW/PYvdpiqGA7XFjvNz XDRDOzSN9cUOR6B5o8AoG+PUDT5C9K2jX7v/cb8BmcobzlsBp/q2ZLfJ/3w29qX0HD D904LYR5RdYIg== Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230630183835.464216-1-sebastian.reichel@collabora.com> References: <20230630183835.464216-1-sebastian.reichel@collabora.com> Subject: Re: [PATCH v3 1/1] clk: divider: Fix divisor masking on 64 bit platforms From: Stephen Boyd Cc: Sebastian Reichel , kernel@collabora.com To: David Laight , Michael Turquette , Sebastian Reichel , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Shevchenko Date: Mon, 23 Oct 2023 20:34:12 -0700 User-Agent: alot/0.10 X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 23 Oct 2023 20:34:26 -0700 (PDT) Quoting Sebastian Reichel (2023-06-30 11:38:35) > The clock framework handles clock rates as "unsigned long", so u32 on > 32-bit architectures and u64 on 64-bit architectures. >=20 > The current code casts the dividend to u64 on 32-bit to avoid a > potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000) > =3D (3.0G + 1.5G - 1) / 1.5G =3D =3D OVERFLOW / 1.5G, which has been > introduced in commit 9556f9dad8f5 ("clk: divider: handle integer overflow > when dividing large clock rates"). >=20 > On 64 bit platforms this masks the divisor, so that only the lower > 32 bit are used. Thus requesting a frequency >=3D 4.3GHz results > in incorrect values. For example requesting 4300000000 (4.3 GHz) will > effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX) > is a bit of a special case, since that still returns correct values as > long as the parent clock is below 8.5 GHz. >=20 > Fix this by introducing a new helper, which avoids the overflow > by using a modulo operation instead of math tricks. This avoids > any requirements on the arguments (except that divisor should not > be 0 obviously). >=20 > Signed-off-by: Sebastian Reichel > --- Sorry this one fell off my review list :( > Changes since PATCHv2: > * https://lore.kernel.org/all/20230526171057.66876-1-sebastian.reichel@c= ollabora.com/ > * Drop first patch (applied) > * Update second patch to use newly introduced DIV_ROUND_UP_NO_OVERFLOW >=20 > Changes since PATCHv1: > * https://lore.kernel.org/linux-clk/20230519190522.194729-1-sebastian.re= ichel@collabora.com/ > * Add Christopher Obbard's Reviewed-by to the first patch > * Update the second patch to use DIV_ROUND_UP instead of DIV64_U64_ROUND= _UP > --- > drivers/clk/clk-divider.c | 6 +++--- > include/linux/math.h | 11 +++++++++++ > 2 files changed, 14 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c > index a2c2b5203b0a..94b4fb66a60f 100644 > --- a/drivers/clk/clk-divider.c > +++ b/drivers/clk/clk-divider.c > @@ -220,7 +220,7 @@ static int _div_round_up(const struct clk_div_table *= table, > unsigned long parent_rate, unsigned long rate, > unsigned long flags) > { > - int div =3D DIV_ROUND_UP_ULL((u64)parent_rate, rate); > + int div =3D DIV_ROUND_UP_NO_OVERFLOW(parent_rate, rate); > =20 > if (flags & CLK_DIVIDER_POWER_OF_TWO) > div =3D __roundup_pow_of_two(div); > @@ -237,7 +237,7 @@ static int _div_round_closest(const struct clk_div_ta= ble *table, > int up, down; > unsigned long up_rate, down_rate; > =20 > - up =3D DIV_ROUND_UP_ULL((u64)parent_rate, rate); > + up =3D DIV_ROUND_UP_NO_OVERFLOW(parent_rate, rate); > down =3D parent_rate / rate; > =20 > if (flags & CLK_DIVIDER_POWER_OF_TWO) { > @@ -473,7 +473,7 @@ int divider_get_val(unsigned long rate, unsigned long= parent_rate, > { > unsigned int div, value; > =20 > - div =3D DIV_ROUND_UP_ULL((u64)parent_rate, rate); > + div =3D DIV_ROUND_UP_NO_OVERFLOW(parent_rate, rate); > =20 > if (!_is_valid_div(table, div, flags)) > return -EINVAL; > diff --git a/include/linux/math.h b/include/linux/math.h > index 2d388650c556..cf14d436fc2e 100644 > --- a/include/linux/math.h > +++ b/include/linux/math.h > @@ -36,6 +36,17 @@ > =20 > #define DIV_ROUND_UP __KERNEL_DIV_ROUND_UP > =20 > +/** > + * DIV_ROUND_UP_NO_OVERFLOW - divide two numbers and always round up > + * @n: numerator / dividend > + * @d: denominator / divisor > + * > + * This functions does the same as DIV_ROUND_UP, but internally uses a > + * division and a modulo operation instead of math tricks. This way it > + * avoids overflowing when handling big numbers. > + */ > +#define DIV_ROUND_UP_NO_OVERFLOW(n, d) (((n) / (d)) + !!((n) % (d))) Can you get someone to review/ack this macro? Maybe Andy? > + > #define DIV_ROUND_DOWN_ULL(ll, d) \ > ({ unsigned long long _tmp =3D (ll); do_div(_tmp, d); _tmp; }) >