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 C3C06C433EF for ; Sat, 12 Feb 2022 10:59:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232230AbiBLK7q (ORCPT ); Sat, 12 Feb 2022 05:59:46 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:59596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230370AbiBLK7p (ORCPT ); Sat, 12 Feb 2022 05:59:45 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64DA824BD6; Sat, 12 Feb 2022 02:59:42 -0800 (PST) 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 0FF01B802BD; Sat, 12 Feb 2022 10:59:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C155DC340E7; Sat, 12 Feb 2022 10:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644663579; bh=CEMuvy2r1KPNQwE5XFJkNJGu4R8eD6T2pmx2Vd1YYOs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e3GL42LcXKYTWMdPP6WeRXd5zHkyvrTIPqdOzvCElBMswHLZciV3hzpMnL7Pu9b8l 5OboDCWvEronnqPUvrSXmYtKbzYulA/5D8Wk5CATxkR0jyru02yYYyLhkvbTU1DnL3 UxPC18BUtVVZjzBTurGq7MI4s+KTCwtLqh8ggnE5w+Rq5J0QoOTbsLHlfZ2sODS3du /q6c1uKR38ZLODTkRpdFnezEId1Ahmjz2wx59SlsgaypT/0nXi9UQm46VyO3z9mxV8 P3/ZY6PZjtwRb7ImblUKa/djrmNp4UreU4lm63LdzJzScJJyL8NqRIUf3jMYPdWItq GEhCVQ+c77DFg== Received: from sofa.misterjones.org ([185.219.108.64] helo=billy-the-mountain.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 1nIq7t-007Lli-IC; Sat, 12 Feb 2022 10:59:37 +0000 Date: Sat, 12 Feb 2022 10:59:37 +0000 Message-ID: <87a6ewl59i.wl-maz@kernel.org> From: Marc Zyngier To: Lorenzo Pieralisi Cc: Pali =?UTF-8?B?Um9ow6Fy?= , robh+dt@kernel.org, Bjorn Helgaas , Thomas Petazzoni , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Marek =?UTF-8?B?QmVow7pu?= , Russell King , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 10/11] PCI: mvebu: Implement support for legacy INTx interrupts In-Reply-To: <20220211182137.GA2492@lpieralisi> References: <20220105150239.9628-1-pali@kernel.org> <20220112151814.24361-1-pali@kernel.org> <20220112151814.24361-11-pali@kernel.org> <20220211171917.GA740@lpieralisi> <20220211175202.gku5pkwn5wmjo5al@pali> <20220211182137.GA2492@lpieralisi> 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 (aarch64-unknown-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: lorenzo.pieralisi@arm.com, pali@kernel.org, robh+dt@kernel.org, bhelgaas@google.com, thomas.petazzoni@bootlin.com, kw@linux.com, kabel@kernel.org, rmk+kernel@armlinux.org.uk, linux-pci@vger.kernel.org, linux-kernel@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, 11 Feb 2022 18:21:37 +0000, Lorenzo Pieralisi wrote: >=20 > On Fri, Feb 11, 2022 at 06:52:02PM +0100, Pali Roh=C3=A1r wrote: >=20 > [...] >=20 > > > > @@ -1121,6 +1247,21 @@ static int mvebu_pcie_parse_port(struct mveb= u_pcie *pcie, > > > > port->io_attr =3D -1; > > > > } > > > > =20 > > > > + /* > > > > + * Old DT bindings do not contain "intx" interrupt > > > > + * so do not fail probing driver when interrupt does not exist. > > > > + */ > > > > + port->intx_irq =3D of_irq_get_byname(child, "intx"); > > > > + if (port->intx_irq =3D=3D -EPROBE_DEFER) { > > > > + ret =3D port->intx_irq; > > > > + goto err; > > > > + } > > > > + if (port->intx_irq <=3D 0) { > > > > + dev_warn(dev, "%s: legacy INTx interrupts cannot be masked indiv= idually, " > > > > + "%pOF does not contain intx interrupt\n", > > > > + port->name, child); > > >=20 > > > Here you end up with a new warning on existing firmware. Is it > > > legitimate ? I would remove the dev_warn(). > >=20 > > I added this warning in v2 because Marc wanted it. > >=20 > > Should I (again) remove it in v3? >=20 > No, I asked a question and gave an opinion, I appreciate Marc's concern > so leave it (ie not everyone running a new kernel with new warnings on > existing firmware would be happy - maybe it is a good way of forcing a > firmware upgrade, you will tell me). My concern is that short of being able to mask these interrupts, it is possible for a device to assert an interrupt that no driver handles, and the kernel spurious interrupt detector won't be able to shut it up. At this stage, the machine is totally dead (screaming *level* interrupt). The dev_warn() could toned down to a dev_warn_once() though. M. --=20 Without deviation from the norm, progress is not possible.