From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70BAD2BAF7 for ; Wed, 25 Feb 2026 00:42:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771980177; cv=none; b=B3GOOQ2VwrbUUO97x8/ow2My2yjvIfJUg7YDGCqz4shVJGkRXtA811gzxBlMVdzcVYXp7Lzalj90g66ypP5RywKeyZBJZSq1KFNWciASkY7p0TP0Mbs767RYFTRP7zJw+SPDL6Mm1s87URZatfw2eoPxkhbtkMeqmvW++QgKZFM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771980177; c=relaxed/simple; bh=tl3OPK/hJINVZ0Pvce1rUGnVr5aWQIysiAoOV5Ez3PY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Kr5VA7A3DCRi2IbE8MM706nZgYeEzU2m31vZ336XfPQ1LRl+r2U7TqM3lvRSv23lDfd+4Z1wrRyyNW12pEe5UpVjLkVfodnYMMETdhnzagl4ujdkf6le/Y8AlJEN2DDzheyy8+sCSQQrDrtXDgDQVeFxIH6amGuQDzoZaRIFr7k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CFMrG9/C; arc=none smtp.client-ip=209.85.208.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CFMrG9/C" Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-3878de20527so52278671fa.3 for ; Tue, 24 Feb 2026 16:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771980175; x=1772584975; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=u6iwHZc2jfg2/r/xq9JQ72DyFmTmkaGJ+WYvMYjFtgQ=; b=CFMrG9/CpNvN7nWGKndKAJthxH2pvQF1Q+dzbFYoP7LC/P5BKSkCP0NdEi/JqVU/Ac EcJ3O8YU1zFvjQ1qw5tmY9oKxld+g7uGVlTaPPPdEukqF/eTTWMKsDE9HbSpj9aoDvIj bGd7yYcf8b1ZomRD/b2T8nNs2TKhy9oy2vWkXqIujwDFUixHBe71WCqpyu7J/h1YIk4p DQ+z5r1D5607AjRqWo5lRgK/VSpt0yTPmDMFYZDxOBWoy28NcE7fLzamZh0lucxiIkl0 YQh02Uyb1Ay6KOrRXG0+zkrl1bWNGPmXgrhfEDEuP0MUiP6QLwTpam2a2hS2vXEAGUxs W7IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771980175; x=1772584975; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=u6iwHZc2jfg2/r/xq9JQ72DyFmTmkaGJ+WYvMYjFtgQ=; b=WgOkev2jEeGlTUaXchCG20UYNIW97Dj+N6wpl6wJ4c4fZo8NRDO6KpNNTxEN8k4qEH u/aiNHHrrBgAbEB4sidZLVZD30dFnjLr0Dt/65yd6KzqOzuny1wvmw2H+fZO+puFP88m mTQQF0vwWLbQbcWPZSN5Ml/+3LuHyEhEQrtDVeFGldox67B7BW/yB4ncLIUI6STVu6uG kYNdxHA9EfP1TcGZiLdDod/z4EHJ+YnKIeyk65HXTD4SDQOjcr7h56JP2C6EcRzbdHAp XazI9y3d1eMwkwhsj8gnvx+UtCZEAxz+rpyW/ZEViiEglt/LpWrIG+oTMyNBSgAN4mQP 9A+w== X-Forwarded-Encrypted: i=1; AJvYcCW/YIdyQK3/TOMAu3WDGTktoMvMLu+ESmwuPy2uufnRrK4dPvMhmKiaAOJaMNHI5h09cSmUEnKUJwtGWn0=@vger.kernel.org X-Gm-Message-State: AOJu0YxSZRCmVn6IZjNsDAVSzFQrrqmFwhliELzQknC363hNfaeJEHyK V5OZztPF8lJ+x0Gj8h9jNETNkxc8VeaxCR+efiakI7G1VZuUkr1Rs7bF92UxuW0c X-Gm-Gg: ATEYQzyPuDMck8WuPPQe6TiYvpGR9rvQ/iL7LW41NKnUW/PDjcFTgGcdRUNDnQtvAHr Vn5Tvx63sHFzTnjrzncCRP8zRHbC+au0KjgdfKldTZSgKs3QlpKUmpe1htxYZTHEWqqVQffZ+4d xVD5sa8sylpP9BxvQMR4ghmAae0wVZDWYCn2pm4QGyK+gwcoVLR7Te82Cyuhxomp2WJ8xZIXzpd upfOnM5Nfv9RXjLjOFqMm5zpGOeBtHgHgOpM919oKpqKjioQTg9L9dUkmUo7w5clCQe4Cd0oFOU xwusPbsq8tIJdEGiTZfHVexdjCF37k+fvu1yl4FKfeka6K2OxL7l13//f/8rFXiBHN3J3n5voRJ PM/pbNH4xDvjpWMAAqcAUTJsi0ASdwX5jLEEfZR9t8lKQvzOyN2kvsWrWe5+QJcwMzmWsVfQ2fX JcrPc+abK9NiD9ezJ3ma7GluVwtKORioov79jfFmXdjpyDTJ59klgJg9VhJfse7lckuA6Fvfse6 3o= X-Received: by 2002:a05:600c:5289:b0:480:1b65:b744 with SMTP id 5b1f17b1804b1-483bef5c44fmr5962925e9.28.1771973422565; Tue, 24 Feb 2026 14:50:22 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bd73ea7esm24486485e9.15.2026.02.24.14.50.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 14:50:21 -0800 (PST) Date: Tue, 24 Feb 2026 22:50:20 +0000 From: David Laight To: Brian Masney Cc: Conor Dooley , Claudiu Beznea , Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH 1/3] clk: microchip: core: update to use div64_ul() instead of do_div() Message-ID: <20260224225020.38032819@pumpkin> In-Reply-To: References: <20260222-clk-microchip-pic32-v1-0-ceacbcd515d1@redhat.com> <20260222-clk-microchip-pic32-v1-1-ceacbcd515d1@redhat.com> <20260223090948.7970ca87@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 24 Feb 2026 11:56:03 -0500 Brian Masney wrote: > Hi David, > > On Mon, Feb 23, 2026 at 09:09:48AM +0000, David Laight wrote: > > On Sun, 22 Feb 2026 18:51:04 -0500 > > Brian Masney wrote: > > > > > This driver is currently only compiled on 32-bit MIPS systems. When > > > compiling on 64-bit systems, the build fails with: > > > > > > WARNING: do_div() does a 64-by-32 division, please consider using > > > div64_ul instead. > > > > > > Let's update this to use div64_ul() in preparation for allowing this > > > driver to be compiled on all architectures. > > > > There are a log of 'long' in that code that hold clock frequencies. > > I suspect they should be u32 (I think someone was scared that int might be 16bit). > > Instead of calling: > > do_div(frac, rate); > > Where frac is a u64, and rate is an unsigned long, I could just cast the > rate to a u32 like this: > > do_div(frac, (u32) rate); > > Thoughts? That cast is horrid :-) On x86 (32bit or 64bit) I'm not sure it makes any difference whether you use do_div() or div64_ul(). Other architectures will be different. I originally thought that do_div() was a simpler wrapper on the x86 divide instruction - so required that both the quotient and remainder be 32bits. But Linus corrected me saying it had always generated a 64bit quotient. So on 32bit div64_ul() is pretty much the same code with the same timings. The 'optimised' (and unusual) parameter rules are also pretty much a waste of time, div takes 38/41 clocks on a '386 (I happen to have the book on my desk!) an extra register move wouldn't matter. Divide doesn't get much faster, 64 by 32 speeds up a bit, but you have to get to cannon lake or zen3 to get a significant improvement. zen3+ execute the 128 by 64 divide only slightly slower than 64 by 32. 64bit Intel is another matter entirely. Even coffee lake has: reciprocal u-ops -- ports -- latency throughput DIV r32 10 10 p0 p1 p5 p6 26 6 DIV r64 36 36 p0 p1 p5 p6 35-88 21-83 So the r64 (128 by 64) divide is a lot slower, and especially so when it isn't really needed. Both do_div() and div64_ul() do a 128 by 64 divide. Even though do_div() would be likely faster using the 32bit sequence. (Especially if the condition were fixed to that it used two divides less often.) Still not sure of the numeric domain of 'frac'. David > > Brian > > > > > > > > > > Reported-by: kernel test robot > > > Closes: https://lore.kernel.org/oe-kbuild-all/202601160758.bpkN4546-lkp@intel.com/ > > > Signed-off-by: Brian Masney > > > --- > > > drivers/clk/microchip/clk-core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c > > > index 692152b5094e00bf5acb19a67cf41e6c86b11f35..2e86ad846a66cd5487f5412c09ab0ad25ebe3f79 100644 > > > --- a/drivers/clk/microchip/clk-core.c > > > +++ b/drivers/clk/microchip/clk-core.c > > > @@ -341,7 +341,7 @@ static void roclk_calc_div_trim(unsigned long rate, > > > div = parent_rate / (rate << 1); > > > frac = parent_rate; > > > frac <<= 8; > > > - do_div(frac, rate); > > > + frac = div64_ul(frac, rate); > > > frac -= (u64)(div << 9); > > > > Is that cast in the right place? > > I suspect 'div' can't be large enough to need it, but it's presence makes > > my wonder ... > > > > David > > > > > > > > rodiv = (div > REFO_DIV_MASK) ? REFO_DIV_MASK : div; > > > > > >