From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f68.google.com (mail-oa1-f68.google.com [209.85.160.68]) (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 7E6661ACEDF for ; Mon, 16 Feb 2026 19:02:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771268531; cv=none; b=HmNkPMAqKKQUPpAbXJmcIr4r9T+kO0hF22cBTj4u72o7gdREMOkGauvEkDYwwouynT2oIV5381czyBtXj2n1uSRucJI/krrmr1bZDLtU0dhRiPmGJt5oF9InpQOL4uU+elshTjsRfDsLdFM7Q5jr1pIHeyxKwKe0PtF+37n7e/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771268531; c=relaxed/simple; bh=dPSKZWl7sBfP2MfxJjzmPQmCiILPmFkv6c8hC7edRmE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hGRe2SlJxyTbqtvl0bMeT/3UQrqGSK9oUYTgrY923nrhBoW0BQIkiQJADtuKqE6S5RkYtUqhf5xDFW9sFQNPd4OLhuML2bqIPpiA9+nNpwN1ZAMRzu62if+PAOo8uVihuickWXmegZb1itYqThddxYQiDV67Obh9/TAp1aoQ/5E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=GW1fdILw; arc=none smtp.client-ip=209.85.160.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="GW1fdILw" Received: by mail-oa1-f68.google.com with SMTP id 586e51a60fabf-40970f97638so2149374fac.3 for ; Mon, 16 Feb 2026 11:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1771268528; x=1771873328; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nc6fdFi3PpOoNTYHhslWaUJsykC31/8ZFpVvbIhED1E=; b=GW1fdILwvAzSoYkQymQyK4qBgPg8Vq3HofXr4gmla3CSvr1SP0OdFoGQWOaWBfsH62 M9QLlu/aJBbFkDCkkfkcO5/ndYxBSbajUrsuNq8XYGKQQ/xv6KwHNsmCsfKLN0GyAVrf tYmfeOrVhmwGF95oAY6tg5ZJBREpZlmNAJj2emIEZdUOwBw31Iic/w1Cua83w53Zgzza CW2nzHgMy4OpKKqrD+u6FRyQPoZLBpkDxmdm9O/hFVE97XJ1t2If0NH3iky2v852VPt0 YiXVUI1rdCoUabGYj9V/6Q5iIKseFGP+6HRYaIJTAoSGPFaoEqEUGCX5L5HTNy+0d6CL b1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771268528; x=1771873328; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nc6fdFi3PpOoNTYHhslWaUJsykC31/8ZFpVvbIhED1E=; b=LN/FBcGX5adgSoADAJPUwWo1FQKyRbKXvn5YGHrSnhYwQSxulrLlH1aIlNAx7HMyhN E70ZKaLTMe1jivueZj/C4JgpJCfwMX/2Q/9WoJPFFxkDs0NtWFV490KXmo9yRKbASWaR xBDyuOcAL1eyhsJFO5t0i06emCPlpxmxNw2d18FMHIwrtSaSdyN2QSSWm4eBgbR7OoQl Aoc3KqmaL3gpoaRTUQ6W+mz2qyM9NwRHS44fVMrvKZnCXkImS/UuJSPv69n2Ga+hQzEw LKimu/fsZe1XXsgSn4O0yux0uWCEXUNRY/U6zovYxhgx6KzkrsoRMo1TxDKetppfPs7u 9Myg== X-Forwarded-Encrypted: i=1; AJvYcCUly4YtpWyallE+oYY1hIjn7t7qMQCoNbpZJau91fWem1hM16zBk0Qa6nOfHq4CW6aC2gKQTKEWJqq/gpc=@vger.kernel.org X-Gm-Message-State: AOJu0YwIsCqxzqgsSXYnws6C2dGwmiujPG/rCY0EN0ItwqvXaXWw2P4A 9MxB+lxxT4Ev2jsUJbEFYLS5sZzgGMAniq4GKmi81+wrd1zaT/Tx1pDuypiW3ubH7p7g7jBNLaI i/BiSFdU= X-Gm-Gg: AZuq6aLLuHn+GkSegVxLZED0PVPg76hC+NWhPgyJj3eIhxljo9DnAUXdSAh9WYH0D0k aMdSULAI6eKQ7Cx9qpzVuzQjdOptP/ps3q3uLWPgvxJS8uiA/ecl5rQ0DzQ1k5RzXdFvytIRf+Z 7bVzaJ30+bSTJP9JkmcbImKDrDJfn5w2vtrkMevtfDRWTgS1izeDsJfJl7/CdE/JTH9g2Vq2IuC IlpE+ikgLidlUJmzYpN/pVN24UbP0vFT29ofHUx8uih2cWoQW4dzVtEUgfx8wm6hu40BNRpaadE 5grPqIgCa5cUm1YYaV5M2zyffbXUt5WOXurYoZv/Rif8LHIUqSVWFKCKUnCtZKuftvee+bZCBhc p7ya4W4viG3r/2CzA7VBqOh0CCVp0S9T8tLT3SP024T5rkaCuuV+LzB9bnHWVa2XlRVrAlf+wU1 xl4tq+tFmWqSGgWpp+gQ6ZI6UUcHpndqdi8iF9Ch9IUaVJp1VNElqY8VeYyTan55beL/SoojF6 X-Received: by 2002:a05:6820:610:b0:679:9353:1211 with SMTP id 006d021491bc7-6799353141bmr1339818eaf.78.1771268528343; Mon, 16 Feb 2026 11:02:08 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:2d75:8cf2:6289:6a96? ([2600:8803:e7e4:500:2d75:8cf2:6289:6a96]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-678b13aec01sm4984097eaf.8.2026.02.16.11.02.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Feb 2026 11:02:07 -0800 (PST) Message-ID: Date: Mon, 16 Feb 2026 13:02:07 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] staging: iio: impedance-analyzer: ad5933: use div64_ul() instead of do_div() To: Archit Anant , Andy Shevchenko Cc: jic23@kernel.org, lars@metafoo.de, Michael.Hennerich@analog.com, gregkh@linuxfoundation.org, nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org References: <20260122145633.14938-1-architanant5@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2/16/26 9:52 AM, Archit Anant wrote: > > On Thu, Jan 22, 2026 at 11:33 PM Andy Shevchenko > wrote: >> >> On Thu, Jan 22, 2026 at 10:27:52PM +0530, Archit Anant wrote: >>> (Resending to the list, apologies for the private reply earlier.) >> >> First of all, do no top post! >> >>> Thanks for the review and the detailed math breakdown. >>> >>> I agree that `(freq * BIT_ULL(29)) / mclk` is algebraically superior and >>> improves precision. >>> >>> However, regarding your concern about the original code: >>>> "why the original code drops precision, was it deliberate?" >>> >>> Since I do not have the AD5933 hardware to test if the register expects the >>> truncated value from `(mclk / 4)`, I am hesitant to change the logic in >>> this patch. >>> >>> Would you prefer I: >>> 1. Stick to a purely mechanical change (keep the logic equivalent, just use >>> `div64_ul` and `BIT_ULL(27)` for readability)? >>> 2. Or proceed with the `BIT_ULL(29)` simplification assuming the precision >>> loss was unintentional? >> >> I definitely prefer #2. That's why I plead to AD people to confirm. >> >>> I'm leaning towards #1 for safety, but happy to do #2 if the maintainers >>> (Lars/Michael) think it's safe. > Gentle ping on this. As Andy said, please don't top-post. Put the reply in context to make it easy to see what "this" is referring to. I moved your reply to show what we mean. > > Has anyone from AD had a chance to confirm whether the original > truncation via (mclk / 4) was intentional? > > If there are no objections, I can prepare a v2 using the BIT_ULL(29) > form as suggested. > > Thanks, > Archit Given how old this driver is, I would not expect an reply as the author has likely long forgotten what they were thinking at the time. I would keep the (mclk / 4) as it is to be safe as you suggest. There could be userspace depending on exact values currently being returned. >> >>> On Thu, Jan 22, 2026 at 8:45 PM Andy Shevchenko >>> wrote: >>> >>>> On Thu, Jan 22, 2026 at 05:12:42PM +0200, Andy Shevchenko wrote: >>>>> On Thu, Jan 22, 2026 at 08:26:33PM +0530, Archit Anant wrote: >>>> >>>> ... >>>> >>>>>> - freqreg = (u64)freq * (u64)(1 << 27); >>>>>> - do_div(freqreg, st->mclk_hz / 4); >>>>>> + freqreg = div64_ul((u64)freq * (u64)(1 << 27), >>>>>> + st->mclk_hz / 4); >>>>> >>>>> It can be one line to begin with. >>>>> Then drop that ugly castings and explicit big shifts. >>>>> >>>>> freqreg = div64_ul(BIT_ULL(27) * freq, st->mclk_hz / 4); >>>>> >>>>> Now you can see That 4 is only 2 bits, so this can be written in >>>>> simpler way: >>>>> >>>>> freqreg = div64_ul(BIT_ULL(29) * freq, st->mclk_hz); >>>>> >>>>> which may give a better precision at the end of the day. >>>> >>>> It also might be worth to add a comment on top to explain (with given >>>> context >>>> I don't know if there is already one on top of the function, though). >>>> >>>> And I think we want AD people to comment on this and maybe explain better >>>> the calculations done (and why the original code drops precision, was it >>>> deliberate?). >> >> -- >> With Best Regards, >> Andy Shevchenko >> >> > >