Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp900261pxb; Fri, 28 Jan 2022 12:40:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwx/wcjk5A2AQbpF2hbk4Iss1REGLShvQVwKX2+IxYA4Uleg5bM5QrwY2I866gwNA2HVvCm X-Received: by 2002:a17:907:1b07:: with SMTP id mp7mr8364180ejc.390.1643402453160; Fri, 28 Jan 2022 12:40:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643402453; cv=none; d=google.com; s=arc-20160816; b=q8YGDRQtFpTWWPRtD/YOVAqxevIViK4+wwdQ209BEfzvFR5X8N9GTUsw5xppFQZyCt 2bRB+82tU7/PCrYdDfq25O0uq3O1i02pKHSDykoEr7lX9qfVoRzU8XZ27gOqG6OgbwxN jfeQ+fdHX4ekBGL0bOMAd4C5L83pC1PqpQPS3tnVUBuX5DqLrwCAgVpoFlDCAG/xYAiE gQuPJi6zYr5lbvgBCbJ5n2tPSyOaigpkvhjPvONIg/GQJRwCceiQI3eoMY7WT6MOR0Mt 4DLnBK1QVIpWd8fmxAUr2rn7GvNeR3f+yS9RBRPCdQ3MDuECyWYVdHcmo4TtduLm2FxJ l/yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=wcr9somIvzZFXM+doLeomZA5zif3KjUFitVyFvJeDYo=; b=ep4PM9Co2so3dGesycOpWbV87aVBFoAcuhnD6b1YXSCkzABDRxc4zbKqTesTlkxBy4 Ekp2T8qLzAujiAqFTKsuaYxFAcYAe7P9P1/nd2xNR0EgYN836RzJkCef+7vzVzuUCzxb +FSvsQeRj8d8aWMLxrmc7YyR/gtr2haBH94YgN1SdE9FxEGAVIdTkeqIJgtZmbUqNSl5 dFaB32dHXNsRD/ldR7jlnUXdQnIh8fSMOdUYs84W5vhhnt+v8q9zQ0/JB4NLgLWxnIZj LK+Y+rUZLjrXvjG7p3ePT5F/36EwbhgGay3+DFlb4bdvyJZNalIyH318UOGEokud7rfj COzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Th8UCnAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e11si1917029ejs.479.2022.01.28.12.40.28; Fri, 28 Jan 2022 12:40:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=Th8UCnAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240623AbiA0WiQ (ORCPT + 99 others); Thu, 27 Jan 2022 17:38:16 -0500 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]:56987 "EHLO wnew2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231520AbiA0WiP (ORCPT ); Thu, 27 Jan 2022 17:38:15 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 9C4BA2B00384; Thu, 27 Jan 2022 17:38:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 27 Jan 2022 17:38:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wcr9somIvzZFXM+do LeomZA5zif3KjUFitVyFvJeDYo=; b=Th8UCnAWUfFBauUeRu2r8tL4o/qjWFXUs uJjCsIczCIR7m69lw4gcRi3cHWCHzzC1QQKuFLTFPv0YnqVi1xYyYAfnwhn06jqw 7uKcU+w3jzQMl+2YhuVYJzIBHGbtNFDDJF4Dt8MyuyWrjCUwAoUI86TxUlrljsu4 o2B3OC13bZ5JEqE02ZVHipmOwadF1NQwqu7oouT8kNj0nvKl24Ny3BVWOUBx8QkC F7gGuSyN3QPZYT04TAQ3v8meFfDMy/GNhT0OmXbhk7FH7XLZgkCA5THYqNfDxvMG Ntej5cBSoZJJKYvvigCUu1ZSuPm3/IDbkRZXYtpC+wGjpHgxzd+mA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeefgdduieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffujgfkfhggtgesthdtredttddtvdenucfhrhhomhephfhinhhnucfv hhgrihhnuceofhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgheqnecuggftrfgrth htvghrnhepffduhfegfedvieetudfgleeugeehkeekfeevfffhieevteelvdfhtdevffet uedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfh hthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jan 2022 17:38:09 -0500 (EST) Date: Fri, 28 Jan 2022 09:37:58 +1100 (AEDT) From: Finn Thain To: Tom Rix cc: kashyap.desai@broadcom.com, sumit.saxena@broadcom.com, shivasharan.srikanteshwara@broadcom.com, jejb@linux.ibm.com, martin.petersen@oracle.com, nathan@kernel.org, ndesaulniers@google.com, megaraidlinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH] scsi: megaraid: cleanup formatting of megaraid In-Reply-To: <20220127151945.1244439-1-trix@redhat.com> Message-ID: <953eb015-4b78-f7b-5dc1-6491c6bf27e@linux-m68k.org> References: <20220127151945.1244439-1-trix@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Jan 2022, trix@redhat.com wrote: > From: Tom Rix > > checkpatch reports several hundred formatting errors. Run these files > through clang-format and knock off some of them. > That method seems like a good recipe for endless churn unless checkpatch and clang-format really agree about these style rules. Why use checkpatch to assess code style, if we could simply diff the existing source with the output from clang-format... but it seems that clang-format harms readability, makes indentation errors and uses inconsistent style rules. Some examples: > static unsigned short int max_sectors_per_io = MAX_SECTORS_PER_IO; > module_param(max_sectors_per_io, ushort, 0); > -MODULE_PARM_DESC(max_sectors_per_io, "Maximum number of sectors per I/O request (default=MAX_SECTORS_PER_IO=128)"); > - > +MODULE_PARM_DESC( > + max_sectors_per_io, > + "Maximum number of sectors per I/O request (default=MAX_SECTORS_PER_IO=128)"); > > static unsigned short int max_mbox_busy_wait = MBOX_BUSY_WAIT; > module_param(max_mbox_busy_wait, ushort, 0); > -MODULE_PARM_DESC(max_mbox_busy_wait, "Maximum wait for mailbox in microseconds if busy (default=MBOX_BUSY_WAIT=10)"); > +MODULE_PARM_DESC( > + max_mbox_busy_wait, > + "Maximum wait for mailbox in microseconds if busy (default=MBOX_BUSY_WAIT=10)"); > This code is longer for no real improvement. > > /* > * The File Operations structure for the serial/ioctl interface of the driver > */ > static const struct file_operations megadev_fops = { > - .owner = THIS_MODULE, > - .unlocked_ioctl = megadev_unlocked_ioctl, > - .open = megadev_open, > - .llseek = noop_llseek, > + .owner = THIS_MODULE, > + .unlocked_ioctl = megadev_unlocked_ioctl, > + .open = megadev_open, > + .llseek = noop_llseek, > }; > > /* Readability loss. > - prod_info_dma_handle = dma_map_single(&adapter->dev->dev, > - (void *)&adapter->product_info, > - sizeof(mega_product_info), > - DMA_FROM_DEVICE); > + prod_info_dma_handle = dma_map_single( > + &adapter->dev->dev, (void *)&adapter->product_info, > + sizeof(mega_product_info), DMA_FROM_DEVICE); > Note the orphaned first parameter and odd indentation. > > static DEF_SCSI_QCMD(megaraid_queue) > > -/** > + /** > * mega_allocate_scb() > * @adapter: pointer to our soft state > * @cmd: scsi command from the mid-layer Indentation error. > @@ -418,15 +409,14 @@ static DEF_SCSI_QCMD(megaraid_queue) > * Allocate a SCB structure. This is the central structure for controller > * commands. > */ > -static inline scb_t * > -mega_allocate_scb(adapter_t *adapter, struct scsi_cmnd *cmd) > + static inline scb_t *mega_allocate_scb(adapter_t *adapter, > + struct scsi_cmnd *cmd) > { > struct list_head *head = &adapter->free_list; Same. > @@ -586,26 +568,25 @@ mega_build_cmd(adapter_t *adapter, struct scsi_cmnd *cmd, int *busy) > > ldrv_num = mega_get_ldrv_num(adapter, cmd, channel); > > - > max_ldrv_num = (adapter->flag & BOARD_40LD) ? > - MAX_LOGICAL_DRIVES_40LD : MAX_LOGICAL_DRIVES_8LD; > + MAX_LOGICAL_DRIVES_40LD : > + MAX_LOGICAL_DRIVES_8LD; > Churn, if not readability loss. Note the indentation change here is inconsistent with the indentation change noted above. > * 6-byte READ(0x08) or WRITE(0x0A) cdb > */ > - if( cmd->cmd_len == 6 ) { > - mbox->m_out.numsectors = (u32) cmd->cmnd[4]; > - mbox->m_out.lba = > - ((u32)cmd->cmnd[1] << 16) | > - ((u32)cmd->cmnd[2] << 8) | > - (u32)cmd->cmnd[3]; > + if (cmd->cmd_len == 6) { > + mbox->m_out.numsectors = (u32)cmd->cmnd[4]; > + mbox->m_out.lba = ((u32)cmd->cmnd[1] << 16) | > + ((u32)cmd->cmnd[2] << 8) | > + (u32)cmd->cmnd[3]; > > mbox->m_out.lba &= 0x1FFFFF; > Here, the orphaned term is moved up, next to the =. And yet, > > /* Calculate Scatter-Gather info */ > - mbox->m_out.numsgelements = mega_build_sglist(adapter, scb, > - (u32 *)&mbox->m_out.xferaddr, &seg); > + mbox->m_out.numsgelements = > + mega_build_sglist(adapter, scb, > + (u32 *)&mbox->m_out.xferaddr, > + &seg); > > return scb; > ... here the first term is moved down and orphaned, which is another inconsistency.