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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10911C433E3 for ; Sat, 25 Jul 2020 08:48:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3F32206D7 for ; Sat, 25 Jul 2020 08:48:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726904AbgGYIsS (ORCPT ); Sat, 25 Jul 2020 04:48:18 -0400 Received: from retiisi.org.uk ([95.216.213.190]:49560 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726593AbgGYIsS (ORCPT ); Sat, 25 Jul 2020 04:48:18 -0400 Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::80:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 8BA2F634C87; Sat, 25 Jul 2020 11:47:40 +0300 (EEST) Received: from sailus by valkosipuli.localdomain with local (Exim 4.92) (envelope-from ) id 1jzFqG-0000kc-Bl; Sat, 25 Jul 2020 11:47:40 +0300 Date: Sat, 25 Jul 2020 11:47:40 +0300 From: Sakari Ailus To: Kieran Bingham Cc: Kieran Bingham , linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mauro Carvalho Chehab , Laurent Pinchart , Jacopo Mondi , Niklas =?iso-8859-1?Q?S=F6derlund?= , Hans Verkuil , Hyun Kwon , Manivannan Sadhasivam , Rob Herring , Linus Walleij , Jacopo Mondi , Laurent Pinchart , Niklas =?iso-8859-1?Q?S=F6derlund?= Subject: Re: [PATCH v10 2/4] media: i2c: Add MAX9286 driver Message-ID: <20200725084740.GD829@valkosipuli.retiisi.org.uk> References: <20200612144713.502006-1-kieran.bingham+renesas@ideasonboard.com> <20200612144713.502006-3-kieran.bingham+renesas@ideasonboard.com> <1fb4a023-d177-744f-41f4-755aafbfa7f2@ideasonboard.com> <20200723222834.GC829@valkosipuli.retiisi.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kieran, On Fri, Jul 24, 2020 at 10:32:11AM +0100, Kieran Bingham wrote: > Hi Sakari, > > On 23/07/2020 23:28, Sakari Ailus wrote: > > Hi Kieran, > > > > On Thu, Jul 16, 2020 at 10:02:24AM +0100, Kieran Bingham wrote: > >> Hi Sakari, > >> > >> This is the output of checkpatch --strict on this driver. Sorry for not > >> detailing this in the commit or cover letter. > > > > No worries. > > > >> > >>> ./patches/gmsl/v10/v10-0001-dt-bindings-media-i2c-Add-bindings-for-Maxim-Int.patch has style problems, please review. > >>> -------------------------------------------------------------- > >>> ./patches/gmsl/v10/v10-0002-media-i2c-Add-MAX9286-driver.patch > >>> -------------------------------------------------------------- > >>> CHECK: Prefer using the BIT macro > >>> #246: FILE: drivers/media/i2c/max9286.c:40: > >>> +#define MAX9286_FSYNCMODE_INT_OUT (1 << 6) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #251: FILE: drivers/media/i2c/max9286.c:45: > >>> +#define MAX9286_FSYNCMETH_SEMI_AUTO (1 << 0) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #262: FILE: drivers/media/i2c/max9286.c:56: > >>> +#define MAX9286_EDC_6BIT_CRC (1 << 5) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #268: FILE: drivers/media/i2c/max9286.c:62: > >>> +#define MAX9286_HVSRC_D14 (1 << 0) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #286: FILE: drivers/media/i2c/max9286.c:80: > >>> +#define MAX9286_DATATYPE_RGB565 (1 << 0) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #304: FILE: drivers/media/i2c/max9286.c:98: > >>> +#define MAX9286_I2CSLVSH_469NS_234NS (1 << 5) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #312: FILE: drivers/media/i2c/max9286.c:106: > >>> +#define MAX9286_I2CMSTBT_28KBPS (1 << 2) > >>> > >>> CHECK: Prefer using the BIT macro > >>> #316: FILE: drivers/media/i2c/max9286.c:110: > >>> +#define MAX9286_I2CSLVTO_256US (1 << 0) > >> > >> None of those are appropriate to use the BIT() macro, as they are all > >> entries of a specific field with a shift, such as: > >> > >> #define MAX9286_FSYNCMODE_ECU (3 << 6) > >> #define MAX9286_FSYNCMODE_EXT (2 << 6) > >> #define MAX9286_FSYNCMODE_INT_OUT (1 << 6) > >> #define MAX9286_FSYNCMODE_INT_HIZ (0 << 6) > >> > >> Checkpatch is only picking up on the "1 << x" variant of each entry. > > > > Ideally you should use "1U << x" everywhere. If you happen to have a > > register with 31st bit signifying something, mayhem would follow. So the > > practice is to make all such definitions unsigned. > > Just to clarify, because of the location you've put your x, which is not > the variable in the above case. > > These definitions are possible field values with a shift (enum << y), > not bit values (1 << x) > > They can of course be unsigned though. > > Is your statement that you would like to see these as: > > #define MAX9286_FSYNCMODE_ECU (3U << 6) > #define MAX9286_FSYNCMODE_EXT (2U << 6) > #define MAX9286_FSYNCMODE_INT_OUT (1U << 6) > #define MAX9286_FSYNCMODE_INT_HIZ (0U << 6) Yes, please. This avoids shifting a non-zero bit to the 31st position of a 32-bit register. > > > Or that you would prefer a macro'ised version: > > #define FIELD_ENTRY(value, shift) (value U << shift) > > > Or rather, I could just convert them all to use FIELD_PREP: > > #define MAX9286_FSYNCMODE GENMASK(7,6) > > #define MAX9286_FSYNCMODE_ECU FIELD_PREP(MAX9286_FSYNCMODE, 3) > #define MAX9286_FSYNCMODE_EXT FIELD_PREP(MAX9286_FSYNCMODE, 2) > #define MAX9286_FSYNCMODE_INT_OUT FIELD_PREP(MAX9286_FSYNCMODE, 1) > #define MAX9286_FSYNCMODE_INT_HIZ FIELD_PREP(MAX9286_FSYNCMODE, 0) > > If you want me to change these entries, I suspect moving wholly to use > FIELD_PREP/FIELD_GET throughout the driver would be the best course of > action. > > A bit of churn, but I can do that if you wish. > > -- > Kieran > > > > >>> CHECK: Macro argument reuse 'source' - possible side-effects? > >>> #399: FILE: drivers/media/i2c/max9286.c:193: > >>> +#define for_each_source(priv, source) \ > >>> + for ((source) = NULL; ((source) = next_source((priv), (source))); ) > >> > >> This warns against possible side effects, but the 're-use' effects are > >> desired ;-) > >> > >> If you'd prefer this macro to be re-written please let me know. > > > > Works for me. Some warnigns are just not useful. I bet quite a few macros > > elsewhere in the kernel would trigger this. > > > I think we'll just leave this one ;-) > > > >>> CHECK: Lines should not end with a '(' > >>> #1372: FILE: drivers/media/i2c/max9286.c:1166: > >>> + ret = v4l2_fwnode_endpoint_parse( > >> > >> Full code block: > >> > >>> ret = v4l2_fwnode_endpoint_parse( > >>> of_fwnode_handle(node), &vep); > >>> if (ret) { > >>> of_node_put(node); > >>> return ret; > >>> } > >> > >> That one is awkward, and I chose to keep it as a lesser evil. > >> Of course now that we can officially go up to 120 chars, I could move > >> this line up. > >> > >> If you'd like this to be moved to a single line now we can go over 80 > >> chars, please confirm. > > > > I don't mind that. Mauro, any thoughts on this? > > > And I'll let Mauro decide that as it will impact my line-length choices > in the future ;-) I think it's actually much better to end a line with opening parenthesis than have a line longer than 80, but I recognise there are differing opinions. My terminal window width is 80 and having more terminals is more useful than being able to see a rare line over 80 completely. -- Regards, Sakari Ailus