Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5991020pxb; Mon, 14 Feb 2022 12:33:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7HpmrOgdnnYBo1bfsjiiFJy66PZav06m0MJpbICv9fMYPlOeakNBXTSVPcCJctZexjVOE X-Received: by 2002:a65:48cc:: with SMTP id o12mr694972pgs.220.1644870810868; Mon, 14 Feb 2022 12:33:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644870810; cv=none; d=google.com; s=arc-20160816; b=JqbT7ZmOMlbd3ZChhQktxfXPhEOsvp1tR4YChE8X5Pv+kJWcFUW11fELcLSP1cX7Zf rPqRen30+witWouSxI5h9tZFEQ81YXcYj7qU7cZVdaiEhSAN9LOQS3HF/fb082fsBayB rT8YKbHeAEBbiT1RX4BI12SDe2k/1W+Y+HnJmhVDcDbdWG0Y20jr4A31HomBAKI/zFT7 PZMsIPMFlHynDj5hiP3EBPNv3uFFJQUZaLsXbmd7eXAKfrhIZR9Kf4xbYvCWwnLuvwaW kjWi7gMFMm0+lT22RpkuEpoB2r6fr+dOFkWpypU/4k/EJttnctNqOWMgEIjp9/ZE/0lL Ng3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to :dkim-signature:date; bh=MlZxepE7UcCIx7JdbAa36YidmF6d5y+C8F78t64Xio0=; b=zK72rmQdR2oNbJIu5cS3BIOvQSC7Az3MLYkooHtbIW1I5KBqSFdSf0iYVANw7ceP7J c/1NNzYN3FGDvtjrdVTdP0RsGz2nQjLRB71eJD6pON0uai6hpcU4xHWYziY+WTH/RSIV bxMwT8+Mj7uzBDMu31jTqt4U9WtoTRPvf/s+lEBjNn7T7pUke0NMR3TgPIJ2UUFXMDHB fOvGZJXVt4F3VljDEmwS9H2dIU4pgSotCamtls+2lyWhb8eyQm4FStXJZDTFeo0QPQAS 3X9SUKj9fBO3lrl6I73mM1HrDSTT3aVx+rjgAN0GqdJMSUVaQsCbBQeh45zzAVTgp/5V CPUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@emersion.fr header.s=protonmail2 header.b=LThY4lgU; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=emersion.fr Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h12si14402817plo.442.2022.02.14.12.33.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 12:33:30 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@emersion.fr header.s=protonmail2 header.b=LThY4lgU; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=emersion.fr Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EC02B19BFAA; Mon, 14 Feb 2022 12:03:15 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351113AbiBNLZ1 (ORCPT + 99 others); Mon, 14 Feb 2022 06:25:27 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:52392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351100AbiBNLYu (ORCPT ); Mon, 14 Feb 2022 06:24:50 -0500 X-Greylist: delayed 503 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 14 Feb 2022 03:00:40 PST Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD93E6A04A for ; Mon, 14 Feb 2022 03:00:40 -0800 (PST) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail-4321.protonmail.ch (Postfix) with ESMTPS id 4Jy1JM4G1Nz4x0y4 for ; Mon, 14 Feb 2022 10:52:19 +0000 (UTC) Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=emersion.fr header.i=@emersion.fr header.b="LThY4lgU" Date: Mon, 14 Feb 2022 10:52:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1644835934; bh=MlZxepE7UcCIx7JdbAa36YidmF6d5y+C8F78t64Xio0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=LThY4lgUqhN8sGqwUbzGNFG1jSZlOqseiQAm9FRwnlotQK8Bibz9NV5fvBRzZkA6e AKdMcgVjEBUpigN+wbQqLLFpMpKqwoX4f/XY+4BKYUTk9WLnDIkOhF2IYvOYMxXq4H /+su7TPrhRIkglRZdbbO4kQikJA2b6Qjq8D6y/OXk1/hIsJfRqkNgbPpDFTLkhegbZ iaoLIMVLTzrHznyG58N/ooRjJnqpJpXq5iboveuFIgQPg4EJtHXoDn2D6MvMkgbJTs nms6hiOAFWrVqs6w8Er37CEQVw+JzcW3PYzmzFJVIQyOmoq/+Qd497VPQPxmkUH7FK VPZyRvj0tT/IA== To: Andy Shevchenko From: Simon Ser Cc: Thomas Zimmermann , linux-fbdev@vger.kernel.org, David Airlie , Daniel Vetter , Javier Martinez Canillas , linux-kernel@vger.kernel.org, =?utf-8?Q?Noralf_Tr=C3=B8nnes?= , Geert Uytterhoeven , dri-devel@lists.freedesktop.org, Sam Ravnborg , Maxime Ripard Reply-To: Simon Ser Subject: Re: [PATCH v4 1/6] drm/format-helper: Add drm_fb_xrgb8888_to_gray8_line() Message-ID: In-Reply-To: References: <20220211091927.2988283-1-javierm@redhat.com> <20220211091927.2988283-2-javierm@redhat.com> <4fa465d9-4fac-4199-9a04-d8e09d164308@redhat.com> <7560cd10-0a7c-3fda-da83-9008833e3901@suse.de> <87pmnt7gm3.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, February 14th, 2022 at 11:38, Andy Shevchenko wrote: > > > > IMO *always* prefer a for loop over while or do-while. > > > > > > > > The for (i =3D 0; i < N; i++) is such a strong paradigm in C. You > > > > instantly know how many times you're going to loop, at a glance. No= t so > > > > with with the alternatives, which should be used sparingly. > > > > > > while () {} _is_ a paradigm, for-loop is syntax sugar on top of it. > > > > Naw, that's not true. > > In the section 3.5 "Loops - While and For" in "The C Programming > Language" 2nd by K&R, the authors said: > > =09The for statement ... is equivalent to ... while..." > > They said that for is equivalent to while, and not otherwise. > > Also, syntax sugar by definition declares something that can be written a= s > a single line of code, which usually is done using more (not always). arr[i] is syntaxic sugar for *(arr + i), yet we keep writing the former, because it's way more readable. The same goes for the for vs. while loops. It may be obvious for you because you're a C guru, but to me it just obfusc= ates the code. Too many C projects end up becoming completely unreadable because= of patterns like these. Idiomatic C code isn't written by doing pointless micro-optimizations.