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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1969C433FE for ; Tue, 5 Oct 2021 15:42:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A7866115A for ; Tue, 5 Oct 2021 15:42:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235510AbhJEPoX convert rfc822-to-8bit (ORCPT ); Tue, 5 Oct 2021 11:44:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:44544 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231513AbhJEPoW (ORCPT ); Tue, 5 Oct 2021 11:44:22 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 502CD61131; Tue, 5 Oct 2021 15:42:32 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mXmaM-00EvaV-Ai; Tue, 05 Oct 2021 16:42:30 +0100 Date: Tue, 05 Oct 2021 16:42:29 +0100 Message-ID: <87lf37qxzu.wl-maz@kernel.org> From: Marc Zyngier To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Marek =?UTF-8?B?QmVow7pu?= , Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , linux-pci@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 06/13] PCI: aardvark: Do not clear status bits of masked interrupts In-Reply-To: <20211005131545.ol3rb3zzgzze67uf@pali> References: <20211001195856.10081-1-kabel@kernel.org> <20211001195856.10081-7-kabel@kernel.org> <20211004140653.GB24914@lpieralisi> <871r50st5h.wl-maz@kernel.org> <20211005141340.48c8c0f6@dellmb> <87mtnnr6cl.wl-maz@kernel.org> <20211005131545.ol3rb3zzgzze67uf@pali> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pali@kernel.org, kabel@kernel.org, lorenzo.pieralisi@arm.com, thomas.petazzoni@bootlin.com, bhelgaas@google.com, linux-pci@vger.kernel.org, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Tue, 05 Oct 2021 14:15:45 +0100, Pali Rohár wrote: > > Hello! > > I dislike this approach. It adds another magic number which is just > causing issues. Please read commit message for patch 11/13 where we > describe why such magic constants are bad and already caused lot of > issues in this driver. As I said, feel free to write something better. > > > > > /* Process MSI interrupts */ > > > > if (isr0_status & PCIE_ISR0_MSI_INT_PENDING) > > > > advk_pcie_handle_msi(pcie); > > > > > > > > /* Process legacy interrupts */ > > > > - for (i = 0; i < PCI_NUM_INTX; i++) { > > > > - if (!(isr1_status & PCIE_ISR1_INTX_ASSERT(i))) > > > > - continue; > > > > - > > > > + for_each_set_bit(i, &isr1_status, PCI_NUM_INTX) { > > > > advk_writel(pcie, PCIE_ISR1_INTX_ASSERT(i), > > > > PCIE_ISR1_REG); > > > > > > 1. what you are doing here is code cleanup. We are currently in the > > > state where we have lots of fixes for this driver, which we are > > > hoping will go also to stable. > > > > Yes, it is code cleanup. Because I don't find this patch to be very > > good, TBH. As for going into stable, that's not relevant for this > > discussion. > > > > > Some of them depend on these changes. > > > Can we please first apply those fixes (we want to send them in > > > batches to avoid sending 60 patchs in one series, since last time > > > nobody wanted to review all of that) and do this afterwards? > > > > It would be better to start with patches that are in a better > > shape. After all, this is what the code review process is about. This > > isn't "just take my patches". > > > > > 2. you are throwing away lower 8 bits of isr1_status. We have follow-up > > > patches (not in this series, but in another batch which we want to > > > send after this) that will be using those lower 8 bits, so we do not > > > want to throw away them now. > > > > I'm discarding these bits because *in isolation*, that's the correct > > thing to do. Feel free to propose a better patch that doesn't discard > > these bits and still makes the code more palatable. > > The code pattern in this function is: compose irs*_status variable and > then compare it with register macros defined at the top of driver. Each > bit in this register represent some event and for each event there is > simple macro to match. > > So with your proposed change it would break all macros (as they are > going to be shifted by magic constant) and then this code disallow > access to events represented by low bits. And also it makes code pattern > different for isr0_status and isr1_status variables which is very > confusing and probably source for introduction of new bugs. Read what I have said: I'm suggesting changes based on this patch *in isolation*. I don't see any other related patch in my inbox (nor do I want to receive any). Feel free to suggest something better (that's the third time I write this...). > Also the whole early-return optimization can be removed as it does not > change functionality. So we will do so. > > But we do not agree with the lower 8 bit discard of the isr1_status > variable as explained above. > > So if we add the explanation to commit message and drop the early > return, would it be ok? Do what you want. I have no interest in this particular piece of code, and only replied to Lorenzo's request. It doesn't change what I think of this patch, but I have too much on my plate to get dragged into sterile arguments. M. -- Without deviation from the norm, progress is not possible.