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 90A2AC433F5 for ; Mon, 10 Jan 2022 15:19:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236088AbiAJPTf (ORCPT ); Mon, 10 Jan 2022 10:19:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236085AbiAJPTe (ORCPT ); Mon, 10 Jan 2022 10:19:34 -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 4ED3DC06173F for ; Mon, 10 Jan 2022 07:19:34 -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 18D5CB81649 for ; Mon, 10 Jan 2022 15:19:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C146C36AE5; Mon, 10 Jan 2022 15:19:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641827971; bh=aZhQbEyF7vRdK8xCqH1U68jQTLsHNHruPWc3aZkJjzI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I34LhhvfBl6iamTOVTEbL25MvVaLuiEDR4e88n5Hmp5kq7r0m+8oi04IFtuETWYxE nVg1BOL+PPyDFPoPAP7P/28YDQFVUTqxMQkjl7bVQH9HotaztFzm60n88U2lFtZevg XWQMr+zu/2jf02I5iL4vahkkZiCjMqYzWUS6pHtb0uQleII49dhGLsjSsn/r3RIraW CNiAutAqg4L3lliAdNIOgSRefm1dfamFfP1wS5+ZrO+d4VDYzLRGQckFde0gdleXmA tyFZUkENpcNXY8hBqCE2TtRkr7GX5PLb3Sjn1t1iDlg6sYHcv672ST7Y2eOTK398Nc IWaFtdhuDpqpA== Date: Mon, 10 Jan 2022 16:19:27 +0100 From: Marek =?UTF-8?B?QmVow7pu?= To: Marc Zyngier , Pali =?UTF-8?B?Um9ow6Fy?= Cc: Lorenzo Pieralisi , Bjorn Helgaas , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 23/23] PCI: aardvark: Make main irq_chip structure a static driver structure Message-ID: <20220110161927.64362d52@thinkpad> In-Reply-To: <87mtk3tzum.wl-maz@kernel.org> References: <20220110015018.26359-1-kabel@kernel.org> <20220110015018.26359-24-kabel@kernel.org> <20220110105324.jud6bzdtmoiuvyas@pali> <87mtk3tzum.wl-maz@kernel.org> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Mon, 10 Jan 2022 14:44:17 +0000 Marc Zyngier wrote: > On Mon, 10 Jan 2022 10:53:24 +0000, > Pali Roh=C3=A1r wrote: > >=20 > > On Monday 10 January 2022 09:28:39 Marc Zyngier wrote: =20 > > > On 2022-01-10 01:50, Marek Beh=C3=BAn wrote: =20 > > > > Marc Zyngier says [1] that we should use struct irq_chip as a global > > > > static struct in the driver. Even though the structure currently > > > > contains a dynamic member (parent_device), Marc says [2] that he pl= ans > > > > to kill it and make the structure completely static. > > > >=20 > > > > We have already converted others irq_chip structures in this driver= in > > > > this way, but we omitted this one because the .name member is > > > > dynamically created from device's name, and the name is displayed in > > > > sysfs, so changing it would break sysfs ABI. > > > >=20 > > > > The rationale for changing the name (to "advk-INT") in spite of sys= fs > > > > ABI, and thus allowing to convert to a static structure, is that af= ter > > > > the other changes we made in this series, the IRQ chip is basically > > > > something different: it no logner generates ERR and PME interrupts = (they > > > > are generated by emulated bridge's rp_irq_chip). =20 > > >=20 > > > There is no 'is spite of the ABI'. If you don't understand why > > > we don't break the ABI, you have an even bigger problem. > > >=20 > > > So NAK to this patch, now and forever. Any change to the structure to > > > make it read-only must allow the preservation of the existing names > > > when they are generated by the driver. =20 > >=20 > > Marc, you already presented that you do not like Armada 3720 platform > > and that you do not care about it. =20 >=20 > What I like or not is irrelevant here. What I ask for is that > userspace ABIs are not broken. >=20 > > But please do not slowdown development for this platform. =20 >=20 > That's quite an accusation. >=20 > > Arguments about ABIs, breaking it and similar are not relevant here as > > this current kernel implementation is broken. And has to be replaced by > > a working one. We are doing on it for more than year. > > > > It really does not make sense to try doing some backward compatibility > > with something which is broken by design and does not work. It just take > > lot of time without any value. > >=20 > > We really need to more forward and fix driver as in current state is > > PCIe on Armada 3720 unusable. =20 >=20 > This patch doesn't fix anything. It has the potential to break > userspace, and I'm not having any of it. You may not care about > backward compatibility, but this is thankfully *not* your pet > playground. >=20 > You can claim that I am doing a bad job. In which case, feel free to > submit a patch removing me from the MAINTAINER file, and we can have > that discussion. >=20 > In the meantime, I will continue to oppose these kind of patches that > pretend to 'fix' things without adding any value. >=20 > M. Dear Marc, that is why I put this patch as last patch of this series, so that it could be potentially dropped. I mostly agree with your points, Pali does not. Pali, let's not sabotage ourselves with needless arguments. Marc, Pali means well, but sometimes when he has different opinion, he can get quite argumentative. Let's ignore this patch for now. Marc, what do you think about the other patches? Did you have time to look at them? Thanks. Marek