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 EA0F2C433EF for ; Sat, 7 May 2022 09:42:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384251AbiEGJqa (ORCPT ); Sat, 7 May 2022 05:46:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343969AbiEGJq3 (ORCPT ); Sat, 7 May 2022 05:46:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CA3D14090; Sat, 7 May 2022 02:42:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 90858B83AC8; Sat, 7 May 2022 09:42:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23817C385A5; Sat, 7 May 2022 09:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651916560; bh=4+dyx8oODyTIP1fTleKBIFWbS0FSiB5ywoj/ypnfrS8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Me9Cluf1Hw+dpVj5SxXXe9rTjrwX+oV1DkYfWSm0qmADICDkOH90f4qAxB8mS0l+a kmjIGHeMeblvInhbsshBlTfukoJBu4CjqnWJynp52Ou/jx+689d7o+BZcTm08NXXIs Sh8QYroGGiRhlv/ulrcOtCFW7js5FcKSVS+srFFyU8QzOpnn7DnhpTjB55IQk38epN c5jXshnQT+gRXqseJ7xEEiaO2L7XinPn5+H6z7Y6//jsJ73hniqKEstZCgoX76FXvL /V4pQjHHCmp9hsJTJWjJxgrxNB/s9isIyXYZhtBEJMob4h4YORuezbukxgEu/F5zNB 8pR4eVcGuzm1w== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1nnGxR-009dwj-SC; Sat, 07 May 2022 10:42:37 +0100 Date: Sat, 07 May 2022 10:42:49 +0100 Message-ID: <871qx5ispy.wl-maz@kernel.org> From: Marc Zyngier To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Thomas Gleixner , Rob Herring , Bjorn Helgaas , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Thomas Petazzoni , Lorenzo Pieralisi , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Marek =?UTF-8?B?QmVow7pu?= , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/6] irqchip/armada-370-xp: Implement SoC Error interrupts In-Reply-To: <20220507092054.b7yu23nj667l6xhy@pali> References: <20220506134029.21470-1-pali@kernel.org> <20220506134029.21470-3-pali@kernel.org> <87mtfu7ccd.wl-maz@kernel.org> <20220506183051.wimo7p4nuqfnl2aj@pali> <8735hmijlu.wl-maz@kernel.org> <20220506185546.n5rl3chyyauy4bjt@pali> <87levd7m2n.wl-maz@kernel.org> <20220507092054.b7yu23nj667l6xhy@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: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pali@kernel.org, tglx@linutronix.de, robh+dt@kernel.org, bhelgaas@google.com, andrew@lunn.ch, gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, thomas.petazzoni@bootlin.com, lorenzo.pieralisi@arm.com, kw@linux.com, kabel@kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.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 Sat, 07 May 2022 10:20:54 +0100, Pali Roh=C3=A1r wrote: >=20 > On Saturday 07 May 2022 10:01:52 Marc Zyngier wrote: > > On Fri, 06 May 2022 19:55:46 +0100, > > Pali Roh=C3=A1r wrote: > > >=20 > > > On Friday 06 May 2022 19:47:25 Marc Zyngier wrote: > > > > On Fri, 06 May 2022 19:30:51 +0100, > > > > Pali Roh=C3=A1r wrote: > > > > >=20 > > > > > On Friday 06 May 2022 19:19:46 Marc Zyngier wrote: > > > > > > On Fri, 06 May 2022 14:40:25 +0100, > > > > > > Pali Roh=C3=A1r wrote: > > > > > > >=20 > > > > > > > +static void armada_370_xp_soc_err_irq_unmask(struct irq_data= *d); > > > > > > > + > > > > > > > static inline bool is_percpu_irq(irq_hw_number_t irq) > > > > > > > { > > > > > > > if (irq <=3D ARMADA_370_XP_MAX_PER_CPU_IRQS) > > > > > > > @@ -509,6 +517,27 @@ static void armada_xp_mpic_reenable_perc= pu(void) > > > > > > > armada_370_xp_irq_unmask(data); > > > > > > > } > > > > > > > =20 > > > > > > > + /* Re-enable per-CPU SoC Error interrupts that were enabled= before suspend */ > > > > > > > + for (irq =3D 0; irq < soc_err_irq_num_regs * 32; irq++) { > > > > > > > + struct irq_data *data; > > > > > > > + int virq; > > > > > > > + > > > > > > > + virq =3D irq_linear_revmap(armada_370_xp_soc_err_domain, i= rq); > > > > > > > + if (virq =3D=3D 0) > > > > > > > + continue; > > > > > > > + > > > > > > > + data =3D irq_get_irq_data(virq); > > > > > > > + > > > > > > > + if (!irq_percpu_is_enabled(virq)) > > > > > > > + continue; > > > > > > > + > > > > > > > + armada_370_xp_soc_err_irq_unmask(data); > > > > > > > + } > > > > > >=20 > > > > > > So you do this loop and all these lookups, both here and in the= resume > > > > > > function (duplicated code!) just to be able to call the unmask > > > > > > function? This would be better served by two straight writes o= f the > > > > > > mask register, which you'd conveniently save on suspend. > > > > > >=20 > > > > > > Yes, you have only duplicated the existing logic. But surely th= ere is > > > > > > something better to do. > > > > >=20 > > > > > Yes, I just used existing logic. > > > > >=20 > > > > > I'm not rewriting driver or doing big refactor of it, as this is = not in > > > > > the scope of the PCIe AER interrupt support. > > > >=20 > > > > Fair enough. By the same logic, I'm not taking any change to the > > > > driver until it is put in a better shape. Your call. > > >=20 > > > If you are maintainer of this code then it is expected from _you_ to > > > move the current code into _better shape_ as you wrote and expect. And > > > then show us exactly, how new changes in this driver should look like, > > > in examples. > >=20 > > Sorry, but that's not how this works. You are the one willing to > > change a sub-par piece of code, you get to make it better. You > > obviously have the means (the HW) and the incentive (these patches). > > But you don't get to make something even more unmaintainable because > > you're unwilling to do some extra work. > >=20 > > If you're unhappy with my position, that's fine. I suggest you take it > > with Thomas, and maybe even Linus. As I suggested before, you can also > > post a patch removing me as the irqchip maintainer. I'm sure that will > > spark an interesting discussion. >=20 > You have already suggested it in email [1] but apparently you are _not_ > maintainer of mvebu pci controller. get_maintainer.pl for part about > which you have talked in [1] says: >=20 > $ ./scripts/get_maintainer.pl -f drivers/pci/controller/pci-aardvark.c Remind me which file this patch is touching? > The only _toy_ here is your broken mvebu board which your ego was unable > to fix, and you have put it into recycling pile [2] and since than for > months you are trying to reject every change or improvement in mvebu > drivers and trying to find out a way how to remove all mvebu code, like > if you were not able to fix your toy, then broke it also to all other > people. You have already expressed this, but I'm not going to search > emails more and find these your statements. At this stage, this is pure paranoia. Do you think I am so emotionally attached to HW purity that I would plot the annihilation of some ugly platform? > Sorry, I'm stopping here. This is just a prove that you are not > qualified in reviewing mvebu code. Happy not to have to review this code. Just stop Cc'ing me on your patches, and don't expect me to merge any IRQ related patches coming from you. M. --=20 Without deviation from the norm, progress is not possible.