From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 151AAC433EF for ; Fri, 11 Mar 2022 11:33:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233084AbiCKLe6 (ORCPT ); Fri, 11 Mar 2022 06:34:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230224AbiCKLe5 (ORCPT ); Fri, 11 Mar 2022 06:34:57 -0500 Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 366CBBBE3A for ; Fri, 11 Mar 2022 03:33:53 -0800 (PST) Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 6B0BA83282; Fri, 11 Mar 2022 12:33:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1646998430; bh=uIGqzCRE2RJ9/x1/Nw+c1d0yjrXrbZwVyXY8llXFRx8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JCngCBNmLf9BN70eWH0If6Ose5BPfYX3FKZe0YAs0MzD0HaEu8ZMZoJFpaF054zyO 0SQtHkIz4gDGmm9mwpr2Ebv9fT2lraSd8WEZa4UfOPwGv/BBNM7+5wReJkd81Ck4Ca NfpSt/twBSVwAaWQ6EUi5GzR/4T0ZRnYCHlQKcQZruaLoKgJFMIf4XSFzoO0hP/9Eo jzEZwLvlQ6U9uaV1nl5yTML426/Zi3soZwBD6ERKVBNNVn3oVTuMmh5oVSbF3Mt7Cj gFcNt33bm5tbdjuHmthfFLi84+fIqSd7tKfaNv02pNVZuQspT2ysbwOHbzTd0YMjcy AGnCY/5luH5tQ== Message-ID: <1504edf0-5773-781a-1a4f-056f57dfbf15@denx.de> Date: Fri, 11 Mar 2022 12:33:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 4/6] iio: adc: ti-ads1015: Deduplicate channel macros Content-Language: en-US To: Andy Shevchenko Cc: Andy Shevchenko , linux-iio , Daniel Baluta , Jonathan Cameron References: <20220310003402.490478-1-marex@denx.de> <20220310003402.490478-4-marex@denx.de> <082e1654-74b7-aed2-4915-f8dd304540d6@denx.de> From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On 3/11/22 12:29, Andy Shevchenko wrote: > On Fri, Mar 11, 2022 at 1:55 AM Marek Vasut wrote: >> On 3/10/22 15:25, Andy Shevchenko wrote: >>> On Thu, Mar 10, 2022 at 01:34:00AM +0100, Marek Vasut wrote: > > ... > >>>> Cc: Andy Shevchenko >>>> Cc: Andy Shevchenko >>>> Cc: Daniel Baluta >>>> Cc: Jonathan Cameron >>> >>> You may consider using --cc parameter in `git send-email` to avoid this noise >>> in the commit messages. >> >> This is deliberate so I can keep track of who to CC on which patch. > > You may add the Link tag to lore (which `b4` tool can do > automatically), so you can always access the email from the archives > and track this down. No need to have this in each of the commit > messages. This is used by git-send-email to put the right people on Cc, not by Lore. > ... > >>>> - .realbits = 12, \ >>>> + .realbits = (_realbits), \ >>>> .storagebits = 16, \ >>> >>> This seems inconsistent a bit. What if the next chip wants to have more than >>> 16 bits in realbits? >> >> When such a chip exists, this can be parametrized as well. > > Yes, My point is that it's error prone. Won't IIO core warn if realbits > storagebits ? > ... > >>> I see two options: >>> 1) add static assert to make sure realbits <= storagebits; >> >> Does static_assert work in array of structures (I don't think it does) ? > > You can check, but IIRC some of the macros have it. Don't remember the > details, though. I already checked before replying, hence my question, as I didn't find a way to make it work.