From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 9057E2F12AB for ; Thu, 20 Nov 2025 11:43:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638999; cv=none; b=VSCKiztUgQUikOacAXcmzDySh1d3QFTK2UBLcxFWJhdY1x6R6gMcOhA+a5t6a0gYNw/GNhGD8Sk6f0VDYykvV+uR0u3sm/UU2V7glMam40zhWpo0z73yb/fYMac9mFRp7eLNOrZzPxXi9AHgYiWGvXHlu+C7M31BLlZh0UjLlS0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638999; c=relaxed/simple; bh=xa59kuPUNpKkvvjKOuQWAuMlmxeDYgsH8/Ee352z66I=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=YN5qYEDccGi/xJa0+zACABwSVi9NBcOKDETxAJGBOoIPXYRbZmq6NoHezW7lby7ucGkz+3bOMB/X6xr7v6BSrBsuUB+JfkKMdpbzDAVKSuY9bTLxXmhapB5FVovpQlSAlVXDFN+UZTcZDoDWBsTNvOsu+H58NL5zxbogzYRClCE= 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=T26NRPx1; arc=none smtp.client-ip=209.85.128.54 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="T26NRPx1" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4779cc419b2so8662395e9.3 for ; Thu, 20 Nov 2025 03:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1763638995; x=1764243795; darn=vger.kernel.org; h=mime-version:user-agent:organization:references:in-reply-to:date:cc :to:from:subject:message-id:from:to:cc:subject:date:message-id :reply-to; bh=xa59kuPUNpKkvvjKOuQWAuMlmxeDYgsH8/Ee352z66I=; b=T26NRPx19Gq7mBcZQ5ukmceLHfsN8wgiqHNE/yVpzLWKAWVkpFCIwJxhYsOv61Eczp mCe+oD+hscJaSef3/2gQeDLzNNaNvw8PKC+uQ4RakGNrr8Y9K3c0K/uI+Z3JYTdQChI9 LCRCvWeztbwx+ZEyaq5XIF+e670Myln9KASmFi8S9qGrqPxOrCXVwI2eswuqpsvWT3KE QaKytvlBBg98yYEf3neUTJHoQrTvf4kIQcdPlZBxThaHqQfETfcGWVacA4Yz+Bezae5k bajdO4KeWMFGm5hMEtk3/2sTg698zfU7SmZomUatlrbNF8NzltnKAoci39SlrM6FgmtP Yfpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763638995; x=1764243795; h=mime-version:user-agent:organization:references:in-reply-to:date:cc :to:from:subject:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xa59kuPUNpKkvvjKOuQWAuMlmxeDYgsH8/Ee352z66I=; b=G2xfRAo7lvV1Rzt37SI932HTBGvbZrkkhZIF/wvPamYxvjqBRE8QJSD+aEeEWXJ4w9 zDnCoknQzAYjhnnl3gc9aBDy2PXz2DB2uqUePZgLKJwymKQJCs+IMgbosRGxLWGTBeH/ FP+OaXwAmb/p7yL661FGLe6OBpwGErVJtwaJLLesW8xrVS+kPeQF8irMs46vpJgm5XPG P6vOn86tUNYzJODDmXzxXhsl1Sxu5xMdYc8frQLYP0KhLr0v040+NpcwOcK/zk5i0NNX MEK83ps18UU+kztGjx9ClMHNNHprTB6KBKVyQPgERXBAPpL0kk9m6L0pDYVGtXLETzRW CKnQ== X-Forwarded-Encrypted: i=1; AJvYcCUiwtge+dOeeas7DwDFSZjiPbPRYcGDwZDCzY3b3wbjv6C3mRvq0QCmrzfK7T0Xql3CApKD7w9rToHcJQQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwybmtTnzSWESbBCCw1tdZrGl5WYzg7F5Akp5bhoNjqBU+cU2M+ orRX0gubptiIT9EAkrUacWWpPYMfc74aBDFxKd6M7d+PIvOH1vDo0rT9ddVJhBxUj5E= X-Gm-Gg: ASbGncuqQVf/UAtyXQstJtwkpXKQkgUSXMMixq7NemQAb0rC6gCojTsjd+eDDBfkRYR jUS+85QGBq3fD98kzt1FHuwUSZaCosGc+dPtBGmR00DeEDb2T0DN0XIi7z4zN90bU+NDPPPll1v L8AFkJd5KAM0rRrkwniBUFnPodv+Cl8APPafVkanr/uy88p9grP5hJoZDOM/0fzpw16CQj6gAVM t810xEPL8Cuk8edfvWIHPixnJFdXpeNvsqzvWplF6mebfoi5mQTzAQmMdmTSEBz022F5St5Kcyo AI69mTegi1/q7EuNv8eXZqFigjoKVbaYWKLG0DYhIzCNYOPuCgSFknlryTY9ZRq86aWiW4y5XIL LdEBJjjqWxvMa4Gk9zEl4Iqy2ltve7TbuEIgFn7V9yk4pSfQdo4TGsdCw862CYFgI1jY3 X-Google-Smtp-Source: AGHT+IGfI6DW67Mb09pvyI4K4LXeoJ5qIjMacy7WgY5onPltVyo46Dt0Qy2AB1yeoj383xHFcRbZbA== X-Received: by 2002:a05:600c:c492:b0:477:9e10:3e63 with SMTP id 5b1f17b1804b1-477b8d8f05bmr28214605e9.35.1763638994625; Thu, 20 Nov 2025 03:43:14 -0800 (PST) Received: from [10.203.83.45] ([151.35.142.84]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-477b82d8023sm44808915e9.4.2025.11.20.03.43.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Nov 2025 03:43:14 -0800 (PST) Message-ID: <50107aecc446ba42e312b81e18a6ffe871fa3291.camel@baylibre.com> Subject: Re: [PATCH 8/9] iio: imu: st_lsm6dsx: add event configurability on a per axis basis From: Francesco Lavra To: Andy Shevchenko Cc: Lorenzo Bianconi , Jonathan Cameron , David Lechner , Nuno =?ISO-8859-1?Q?S=E1?= , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 20 Nov 2025 12:43:09 +0100 In-Reply-To: References: <20251030072752.349633-1-flavra@baylibre.com> <20251030072752.349633-9-flavra@baylibre.com> <5b23d077d8882d6b2a2e66817b1b6bcebc6bb5a2.camel@baylibre.com> <82bf13fd5ada664d9e4fdbc3ee453204e55d318b.camel@baylibre.com> Organization: BayLibre Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-GJDC4zqvByph2/4pxtOy" User-Agent: Evolution 3.46.4-2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 --=-GJDC4zqvByph2/4pxtOy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2025-11-20 at 10:05 +0100, Andy Shevchenko wrote: > On Tue, Nov 18, 2025 at 12:01:57PM +0100, Francesco Lavra wrote: > > On Tue, 2025-11-18 at 11:44 +0100, Andy Shevchenko wrote: > > > On Mon, Nov 17, 2025 at 08:23:35PM +0100, Francesco Lavra wrote: > > > > On Thu, 2025-10-30 at 15:56 +0200, Andy Shevchenko wrote: > > > > > On Thu, Oct 30, 2025 at 12:23:19PM +0100, Francesco Lavra wrote: > > > > > > On Thu, 2025-10-30 at 10:24 +0200, Andy Shevchenko wrote: > > > > > > > On Thu, Oct 30, 2025 at 08:27:51AM +0100, Francesco Lavra > > > > > > > wrote: >=20 > ... >=20 > > > > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0old_enable =3D h= w->enable_event[event]; > > > > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0new_enable =3D s= tate ? (old_enable | BIT(axis)) : > > > > > > > > (old_enable > > > > > > > > & > > > > > > > > ~BIT(axis)); > > > > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!!old_enable= =3D=3D !!new_enable) > > > > > > >=20 > > > > > > > This is an interesting check. So, old_enable and new_enable > > > > > > > are > > > > > > > _not_ > > > > > > > booleans, right? > > > > > > > So, this means the check test if _any_ of the bit was set and > > > > > > > kept > > > > > > > set or > > > > > > > none were set > > > > > > > and non is going to be set. Correct? I think a short comment > > > > > > > would be > > > > > > > good to have. > > > > > >=20 > > > > > > old_enable and new_enable are bit masks, but we are only > > > > > > interested > > > > > > in > > > > > > whether any bit is set, to catch the cases where the bit mask > > > > > > goes > > > > > > from > > > > > > zero to non-zero and vice versa. Will add a comment. > > > > >=20 > > > > > If it's a true bitmask (assuming unsigned long type) then all > > > > > this > > > > > can be > > > > > done > > > > > via bitmap API calls. Otherwise you can also compare a Hamming > > > > > weights of > > > > > them > > > > > (probably that gives even the same size of the object file, but > > > > > !! > > > > > instructions > > > > > =C2=A0will be changed to hweight() calls (still a single assembly > > > > > instr on > > > > > modern > > > > > =C2=A0architectures). > > > >=20 > > > > These are u8 variables, so we can't use the bitmap API. > > >=20 > > > OK. But hweight8() can still be used. > > >=20 > > > > And I don't > > > > understand the reason for using hweight(), given that the !! > > > > operators > > > > would still be needed. > > >=20 > > > No, you won't need !! with that. > >=20 > > I still don't understand. Are you proposing to replace `if > > (!!old_enable =3D=3D > > !!new_enable)` with `if (hweight8(old_enable) =3D=3D > > hweight8(new_enable))`? > > That won't work, because we only need to check whether the Hamming > > weight > > goes from zero to non-zero and vice versa. >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 old_enable =3D hw->enable_event[even= t]; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new_enable =3D state ? (old_enable |= BIT(axis)) : > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 (old_enable & ~BIT(axis)); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!!old_enable =3D=3D !!new_enable= ) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 return 0; >=20 > If I am not mistaken this will do exactly the same in a simpler way. >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0old_enable =3D hw->enable= _event[event]; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (state) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0new_enable =3D old_enable | BIT(axis); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0else > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0new_enable =3D old_enable & ~BIT(axis); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if ((new_enable ^ old_ena= ble) !=3D BIT(axis)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0return 0; This doesn't look right to me, if new_enable differs from old_enable by just one bit (which it does), then the XOR result will always have this bit (and no others) set, so (new_enable ^ old_enable) will always equal BIT(axis). We are not checking if the bit was already set or clear, when this code runs we already know that the bit is changing, what we are checking is whether all bits are zero before or after this change. --=-GJDC4zqvByph2/4pxtOy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEhleFT5U73KMewxTm7fE7c86UNl8FAmke/s0ACgkQ7fE7c86U Nl+0Owv9Fd6Xltaw6zl0SO6umBIDy7yyYmxsUv3ilrrapjWyIO6Z1lpvADYrCf9H Kv+7PXPN/gQI47gZU9Dk6AA7AcLyi1khlED08BtbsZg60pJAd5snGcZYVhFojJBN opQ7wW2WpMgMthG/q9de0Kn64vCzTOm5JG9mmu9EbHTZ8zU1K/5lTLPoCPo0DVDM 1462W9JKjUUQm7Xj8F5V7gg2w/byvlfIt5k8ipsEP+5J6egZGQlE5yz/3VgSOVcl wo1MUsgis575CIFbXnhhzyEXX6/1VC0z/agyVum7uJlTCoxptj2m87ncFkzPx40E 7XKX+ky7vS076IVfeN2ovk1Zt3yFZHXX39Iw0WW9siUMNfKUR6S6ObFwN2QYJqgv T+murnhgeDTVK5LpmpgH9cDO6G+CQGxEQLWSHopRbh6vEhjBMWMAkh/pEwxmY8Xr G180UOzjJVscqpqmpMCvgaxco7RMeuBjNZxhLlDUTSsUIdLQNefpk4L5sUWImBRU onk+7iXH =WtqX -----END PGP SIGNATURE----- --=-GJDC4zqvByph2/4pxtOy--