From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 E706D3176EF for ; Sun, 17 May 2026 19:22:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779045729; cv=none; b=kvoPwTNHgJpXVSIfy7AUQHZmUaKViHFqOJ+9SWJx8E0vIE8NgdVyH4o7e/q43cS+ltBJIXuZ8ZyhBLLem2ElOH8cMP3MkKhQPyTS54xMNrtVgXLwsutpAcoVQSY4RGBVWg7mwcLDdwcH6mo96w6YZcLMW4wkXX9vCuCMMup6yi0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779045729; c=relaxed/simple; bh=6F4HRBnD1ijw9LojF5iljzN3VgqrvJ5ysiNE+lXRJWE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jLtdkc/oFlq930/misTF3iCj9RVcIp6Qus4UPe37qrc5l3KWfQhRrq8wlSoMb1u4NRh9mHMMa/RaJaq0Y9njFD38hsTabG68/WJCRMQ38pRPh6PRsyUMN2DreLnnUsxrOtncdqj4eEL8Lqne+3YCp/ub0HtcB8+MM2DEkFYpEPw= 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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=iocBRHyq; arc=none smtp.client-ip=209.85.210.49 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.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="iocBRHyq" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-7dcd9061b1aso1589852a34.2 for ; Sun, 17 May 2026 12:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1779045726; x=1779650526; 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=t8oeugrZbzajef/1vQAam9ttn87tFGEQi6JKVNWh+g0=; b=iocBRHyqpDjJsX6VFYSTVFE2rR207Lw2d9ok8NkEfnXyF6dSLo0iOgwy7bZusWOmz3 x+3FSd6gOGvOgbG6vatDZoZ/cFOY9jGvn+6S6nl04z0FOHmx5LD88t+9kvQ9jOVdRbUD DRlWJTO+PB1ihFLCKYe13qZp1Nj8EkOaIgqgwZt7NGZbTgTrPg72s8ZMgf5f9N5xq34g zodUSTJuqyoso5aXJEcMtCzfO6KGcJip7dqIrkcyv5SfRROEJ+LFpY4xt1l9hnfKwyrc HZW2s6aYGnS6IuHbBPkSqf9EvJAeTTtPMWjnw8TgMdSeAATBGEZ9Cufjxjq2L5SietFb n/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779045726; x=1779650526; 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=t8oeugrZbzajef/1vQAam9ttn87tFGEQi6JKVNWh+g0=; b=ELdGdK7Z9p4bmxszteuYP2JElTN4B4nrTaczPHmPDuMBFZUtfFEEKR/d7fPcPVkTek LQEebOId8aOUKhhdGOevs1QNrrSzm6WfCBYpGu//jxCowV8xKQ4ies0CpYrXjHTRdJC3 1AFulozhVJ6jcfN1r8nWPD5VWJMwEXN39E93iwtWupGtHxFGUYR9ZeUAcWeDrPQ68sl/ La99yZtE6eW7ITrEJqAVAW9y7JZ3KEyI7j8xmcfMsxNcCqj7DMvBt+TKVRlk+zJ+uWo7 SyT1SHAR4W38KkY6ef1BV0VTGW+aoRXlQEwqg/9EEFQc9234IIOXZah1MDnakib6Se8E tb+Q== X-Forwarded-Encrypted: i=1; AFNElJ/1w7970P3EHVf3rEyMSzE7NOIkKQ5eH3tY4DHcbbnLfbp9+O/nDVKmIfDv8faArrlD6tpPb4Is7nEeCmg=@vger.kernel.org X-Gm-Message-State: AOJu0YzVQfcfTQgM5fNZyP6dDldRFSm+0fkrEcRTA85XvlDDcld2oMiM 89sPW8qtD6L+Vio8Y4h+K23Cq1oQe1veEuwPDRy90LL/cg//0MUOg8MMy+RSFIX9rrk= X-Gm-Gg: Acq92OFsecC+KBXRoLnz9Gmp2KTLjrzwch1v6nkUwWjsiN+zuwFaQ6EgMtfeTNV0A31 LBfvAMBTTp3B4p5C+whA1Y89cmLGWVJoZ6X6fPJY6QN/y8ViwmEHVG5m8wxZ4yVskxPs2tmDdzf 367gPokBROGzPCv3UqhlUB4kfVhyySDEjSER07/EwSI7wQS0FJb1bieQpHIDIhYaelPOP6yj5Xw Xj96bkqPCdsy+au5B+u6H2Ho14ot0GM3lHnzrBzs3JXyZNbH1EEDZ7+90XOHneP4Xj5KlIL+bqs s6omTUFj5Y8TrImNZoVuAqRE1bkQvJuznhBoW2p9Hs3JsY8bYiWg77vnVvV9PpwO7tFdLFrxyJ0 kL5gctwrfEx6DADrKv0NtyHRo5FWx/MjMspMLElqVdmnPQyLC5XxHTqqZxJr1n+n8mYlNZHFV68 aB1xlCRhxl/GeKhUaEGDaCcD38iT6+y2Q+z5QH+aNeyyFsLMKExnjl3ayqziA0migQvFVcJTQH2 V9HeKXCfA== X-Received: by 2002:a05:6830:628a:b0:7e3:d199:3164 with SMTP id 46e09a7af769-7e4f2aa4df0mr8632934a34.11.1779045726420; Sun, 17 May 2026 12:22:06 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:7a4b:ddf0:f61:f58d? ([2600:8803:e7e4:500:7a4b:ddf0:f61:f58d]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e55bbd10aesm6121272a34.18.2026.05.17.12.22.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2026 12:22:04 -0700 (PDT) Message-ID: <83c11e2c-9688-4cc9-b7ee-6380de30fb58@baylibre.com> Date: Sun, 17 May 2026 14:22:03 -0500 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 0/8] iio: timestamp declaration cleanup To: Jyoti Bhayana , Jonathan Cameron , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Maxime Coquelin , Alexandre Torgue , Benson Leung , Guenter Roeck Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, chrome-platform@lists.linux.dev References: <20260517-iio-timestamp-cleanup-v1-0-61fb908c11c7@baylibre.com> Content-Language: en-US From: David Lechner In-Reply-To: <20260517-iio-timestamp-cleanup-v1-0-61fb908c11c7@baylibre.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/17/26 1:17 PM, David Lechner wrote: > While looking around the code, I noticed that there are a lot of places > were we are manually filling all of the fields of an IIO timestamp. > > This is error-prone (as seen in the first patch) and more verbose than > it needs to be. > > I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP() > macro for doing a struct assignment. This does require a cast, which > makes it a bit more verbose, but we were already doing that in to > drivers, so I went with it anyway. > > If we want to consider alternatives, we could make a iio helper function > or macro like the first and second patches did. > I should have looked harder for existing alternatives. Just found one more that avoids the cast via a local variable (in ad4170-4.c): /* Add timestamp channel */ struct iio_chan_spec ts_chan = IIO_CHAN_SOFT_TIMESTAMP(chan_num); st->chans[chan_num] = ts_chan; And similar code is found in ad7192.c.