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 939E9C433EF for ; Sat, 7 May 2022 09:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357631AbiEGJGE (ORCPT ); Sat, 7 May 2022 05:06:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230191AbiEGJGD (ORCPT ); Sat, 7 May 2022 05:06:03 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC91DBC23; Sat, 7 May 2022 02:02:16 -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 26477B82A25; Sat, 7 May 2022 09:02:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2F43C385A9; Sat, 7 May 2022 09:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651914133; bh=Mz3xRG4PReFDHkDz1EoW1kUBJgxS84UFJF53AAINPzI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cnNzv0gsBfgs967DWQO5oSuKp7R75NbFYGY++ckFyVDgFxxw1ivFmBZFRjUqpUsdY nWhtxyqGzOTAJwP82ZiIOuuv0iGm0oV99CJgpwKjDRuNL+wTfzxBEdz4W6zioqisa6 cJuRwgxI1Zkqi/94JU0hfw3y+WGIDLWl2cODv3W2SjXtD7kwyUxd041wsh+1w62lEG A0K9qEW5VXujonHWc8QZzU0GGKJKImNFTmjY/QZgDCDM8VJmf4v26Qn4nQFUytS3Un SA0u0i75ExXWAzKN2KNwOREucpZDAe1W51JfG8Z7pmtW4G1PUCAwqGHAEQA6CUhg/L pTN/VRNoyA5Zg== 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 1nnGK1-009dak-2k; Sat, 07 May 2022 10:02:10 +0100 Date: Sat, 07 May 2022 10:01:52 +0100 Message-ID: <87levd7m2n.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: <20220506185546.n5rl3chyyauy4bjt@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> 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 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_percpu(v= oid) > > > > > armada_370_xp_irq_unmask(data); > > > > > } > > > > > =20 > > > > > + /* Re-enable per-CPU SoC Error interrupts that were enabled bef= ore 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, irq); > > > > > + 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 res= ume > > > > function (duplicated code!) just to be able to call the unmask > > > > function? This would be better served by two straight writes of the > > > > mask register, which you'd conveniently save on suspend. > > > >=20 > > > > Yes, you have only duplicated the existing logic. But surely there = 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. 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. 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. > > > > > +static int armada_xp_soc_err_irq_set_affinity(struct irq_data *d, > > > > > + const struct cpumask *mask, > > > > > + bool force) > > > > > +{ > > > > > + unsigned int cpu; > > > > > + > > > > > + cpus_read_lock(); > > > > > + > > > > > + /* First disable IRQ on all cores */ > > > > > + for_each_online_cpu(cpu) > > > > > + smp_call_on_cpu(cpu, armada_370_xp_soc_err_irq_mask_on_cpu, d,= true); > > > > > + > > > > > + /* Select a single core from the affinity mask which is online = */ > > > > > + cpu =3D cpumask_any_and(mask, cpu_online_mask); > > > > > + smp_call_on_cpu(cpu, armada_370_xp_soc_err_irq_unmask_on_cpu, d= , true); > > > > > + > > > > > + cpus_read_unlock(); > > > > > + > > > > > + irq_data_update_effective_affinity(d, cpumask_of(cpu)); > > > > > + > > > > > + return IRQ_SET_MASK_OK; > > > > > +} > > > >=20 > > > > Aren't these per-CPU interrupts anyway? What does it mean to set th= eir > > > > affinity? /me rolls eyes... > > >=20 > > > Yes, they are per-CPU interrupts. But to mask or unmask particular > > > interrupt for specific CPU is possible only from that CPU. CPU 0 just > > > cannot move interrupt from CPU 0 to CPU 1. CPU 0 can only mask that > > > interrupt and CPU 1 has to unmask it. > >=20 > > And that's no different form other per-CPU interrupts that have the > > exact same requirements. NAK to this sort of hacks. >=20 > You forgot to mention in your previous email how to do it, right? So we > are waiting... I didn't forget. I explained that it should be handled just like any other per-CPU interrupt. There is plenty of example of how to do that in the tree (timers, for example), and if you had even looked at it, you'd have seen that your approach most probably results in an arbitrary pointer dereference on anything but CPU0 because the requesting driver knows nothing about per-CPU interrupts. But you're obviously trying to make a very different point here. I'll let you play that game for as long as you want, no skin off my nose. Maybe in the future, you'll be more interested in actively collaborating on the kernel code instead of throwing your toys out of the pram. Thanks, M. --=20 Without deviation from the norm, progress is not possible.