From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 EF76A25F7A5 for ; Sat, 27 Jun 2026 09:14:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782551686; cv=none; b=SnrtQQ57PtaLT7oy/4Xb3Ri94rAjn5ksRlWFDMoOEBWeCbQDBVkLAeYYhJ1AgxN+h2MMxwWV26adWwu+olyVn+iiqWnY+r6njjQOcD0Jxi7fdL8U8NsWGeAEU1K3ohG3nKOZrhz1cYJqfsE8PSTj9dzTkYO3L11+yhkGM3U5O8o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782551686; c=relaxed/simple; bh=Z8uCPIIDNXooRopdDUOK8um3dmG4tMzYyiTEArCN3RE=; h=Mime-Version:Content-Type:Date:Message-Id:From:Subject:Cc:To: References:In-Reply-To; b=rtXZgKJjBEpTgcb/Vxb7nxFwbv2Nqqc8a1bR7VtWqZscjKiojcME+Z+bfZmyaZJy5iFHSA88PDo5/wIH/qginf6TzFq3NZJvt7+h++GulkD0HXeAaNGjt7gmT8V2QQIxHfTSvOq1J3OoCqylvAAlLnhyX6k4bt4/3mOx7NJXieE= 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=L2iZNxAE; arc=none smtp.client-ip=209.85.128.51 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="L2iZNxAE" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4938d60c035so1643455e9.0 for ; Sat, 27 Jun 2026 02:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782551683; x=1783156483; darn=vger.kernel.org; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UIu3t9txoYMi3zO+SM6qADSS3eQfqtRnLd308UxDVsg=; b=L2iZNxAE+GfDf35Dk+f01WuBMdQCktKfGjHNtWcVKuGUIy1+PAwYQl3fOXazrdIghz ZILEx/HBcucajngsfas43pp9VvPGOsUz15dgGel2iqNvEkERXeuKecbTWVX+gHeQUG/Z adopPWpo0sYWXRFfQ8+vqXK1dHcaBtisK0kvOnFv7X10a9dVHjlkB0rCLZ9Zc/jVGMZf k7W99VEYyjD7Z/LkMF2Ng3uQinh8aPH+FkwLVx0Mfr81Npu1o1k05qHNMdnJSazrjetA WROv+/hxo0JsW7QKrYnpTnpellGKMOg8aZFGWHZ5kolCUtbG0U+1Xvur+TVJ8voAkVVa YFRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782551683; x=1783156483; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UIu3t9txoYMi3zO+SM6qADSS3eQfqtRnLd308UxDVsg=; b=pvYWyWG1YlcP8eArf2hP1DScW1Yd2zksF/g2n/Paxg+rIVAxdlUBrVvlh8UnpuzoOY IxAt5edC3cyyw/+Jza1MfKRzy+GjeXangt7jDcJ1WtuihhaVCtkiF7klkm7UQhUSH8FN bW0jr+BwXyk7ar4seu7nI83JuVvDxxJTkpA0RYH6ip3CKb6pbuhQEG+Ll5Gh9+p/KDBZ mXrQWeazlzLqen/4tXjPgOhWi7drq6N4/MU9JEcc7bXs2+yW0mljX09sXFXiLO/SzLz1 XOnC8BJkDDzPFrtxkYCZHndfGy6OYTfg8pGNFth5V1INPfa9zYITL2bcPJPAgZmZz4S2 duBA== X-Forwarded-Encrypted: i=1; AFNElJ/YK/Yz2RCiwfQzO7qG2LN9DoldYCHp6LT6gXmo1tAr0cJcIhb0kp7jqVLln8xKf5dPUbqWqrmg08+c6wI=@vger.kernel.org X-Gm-Message-State: AOJu0YwIZWU2y/uCPOu9tLhsqIkM/ok6xIRIdH4Uox8mFFJ9dWdFCaBd 1S+SxB8FW4XF7Uh6x+qhqQHyTQPSWh078h6vat4vmtUzFQDxrflskawb X-Gm-Gg: AfdE7clFGXOya9l7faw83v5C9p4XY5+814XG1geTh+NDPn7AzIMdmpCs8R7y9cODxXX XEXTGhFTE+d+xYJpVKNojKkwqu3ZDbF8p+vw9ZFPD5VTl/0upYt4L+Im4vvm9r085FNcedAJr8R HdHHEHR2vh+3+NUXEUJ0z08PP4i49B6O001H6g9yMzWVowkAaPXklFYLmI2IerlHE35bqBMiet7 hVXhcbjLyzakM4+W/1chw3ZkqYaEPAG5EWjREijR005GYyIxaNJksnyHO4t3ixgw4NGQlqrb77d Z5kxFLR8BhJyh0IweBAguozg0mp8xRhmXhVLXaKj2fg7RNSbzZryaQiq4GFb3Q/XhQ2RCGSOXJR N+mQMPYgoK0WoGIf/yRDxxyBqWTtDpCrxa/JjxjmHw7Dcv0IAd0OWDs2Yy+LZ2YJC+ejQY6yMZK n83gH1ATviWMra7LzD4WYMT9jhag== X-Received: by 2002:a05:600c:4691:b0:492:4636:87ae with SMTP id 5b1f17b1804b1-49266880f9cmr146104325e9.17.1782551682986; Sat, 27 Jun 2026 02:14:42 -0700 (PDT) Received: from localhost ([2001:4bb8:16f:1117:42e7:2f77:29e1:f0a2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-492690a1a85sm250344055e9.15.2026.06.27.02.14.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2026 02:14:42 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 27 Jun 2026 11:14:39 +0200 Message-Id: From: "Javier Carrasco" Subject: Re: [PATCH v2] iio: light: veml6075: fix UV index reported at half value Cc: "David Lechner" , =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , , To: "Shardul Deshpande" , "Jonathan Cameron" , "Javier Carrasco" X-Mailer: aerc 0.21.0-143-g2f3a2e260c09 References: <20260626110400.68885-1-iamsharduld@gmail.com> <20260627085313.7507-1-iamsharduld@gmail.com> In-Reply-To: <20260627085313.7507-1-iamsharduld@gmail.com> On Sat Jun 27, 2026 at 10:53 AM CEST, Shardul Deshpande wrote: > veml6075_get_uvi_micro() normalises the UV index for the configured > integration time. The raw UVA/UVB counts scale linearly with the > integration time, so the responsivity-weighted sum must be divided by the > integration-time scale factor relative to the 50 ms base case (which is > returned undivided). > > Per the VEML6075 datasheet the UV_IT field selects the integration time > as 50, 100, 200, 400 and 800 ms for field values 0..4, i.e. > (50 << int_index) ms: each step doubles the integration time and hence > the accumulated counts. The correct scale factor relative to the 50 ms > base is therefore 2^int_index =3D=3D (1 << int_index). (See also the Vish= ay > application note "Designing the VEML6075 Into an Application" for the > UV-index responsivity calculation that these constants implement.) > > The code instead divided by (2 << int_index) =3D=3D 2^(int_index + 1), i.= e. > twice the correct value, so the reported UV index was half of the true > value for every integration time except 50 ms. As the driver powers up > with VEML6075_IT_100_MS, the UV index was reported at half value out of > the box. > > Divide by (1 << int_index) instead. int_index is already bounded to 0..4 > by veml6075_read_int_time_index(), and (1 << 0) =3D=3D 1 reproduces the > undivided 50 ms case, so the per-integration-time switch collapses to a > single expression. > > Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor d= river") > Cc: stable@vger.kernel.org > Signed-off-by: Shardul Deshpande > --- > Changes in v2: > - Collapse the per-integration-time switch into a single divide now that > all cases share the same expression -- int_index is bounded to 0..4 by > veml6075_read_int_time_index() and (1 << 0) reproduces the 50 ms case. > (Javier Carrasco) > - Add VEML6075 datasheet (UV_IT integration-time table) and application- > note references for the integration-time scaling in the changelog. > > Link to v1: > https://lore.kernel.org/linux-iio/20260626110400.68885-1-iamsharduld@gmai= l.com/ > > drivers/iio/light/veml6075.c | 18 +++++++----------- > 1 file changed, 7 insertions(+), 11 deletions(-) > > diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c > index 59187244a..d0ec06eeb 100644 > --- a/drivers/iio/light/veml6075.c > +++ b/drivers/iio/light/veml6075.c > @@ -237,17 +237,13 @@ static int veml6075_get_uvi_micro(struct veml6075_d= ata *data, int uva_comp, > if (int_index < 0) > return int_index; > > - switch (int_index) { > - case VEML6075_IT_50_MS: > - return uvia_micro + uvib_micro; > - case VEML6075_IT_100_MS: > - case VEML6075_IT_200_MS: > - case VEML6075_IT_400_MS: > - case VEML6075_IT_800_MS: > - return (uvia_micro + uvib_micro) / (2 << int_index); > - default: > - return -EINVAL; > - } > + /* > + * The raw counts scale linearly with the integration time, which > + * doubles at each step (50, 100, 200, 400, 800 ms =3D=3D 50 << int_ind= ex > + * ms; int_index is bounded to 0..4 above). Normalise to the 50 ms > + * base by dividing by 2^int_index; (1 << 0) =3D=3D 1 leaves 50 ms as-i= s. > + */ > + return (uvia_micro + uvib_micro) / (1 << int_index); > } > > static int veml6075_read_uvi(struct veml6075_data *data, int *val, int *= val2) Hello Shardul, thank your for your patch. Please give potential reviewers more time to take a look at your patches. It's been less than 24 hours between v1 and v2, and that reduces the amount of people who could review and potentially improve your patches. In my opinion, the comment you added is way too verbose, and it includes information that is well known within the driver like the possible values for the integration time. Once it is fixed, it is clear that it is normalised to 50 ms because it is index 0. To be honest, I would even drop the comment completely. Best regards, Javier