From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 154DC1DA60D; Thu, 17 Oct 2024 09:56:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729158992; cv=none; b=hDpSYEhVaqz7n503wEF7E90e5EKtE1Wrr9rBDtVQJEgRoZt586WGnaVnFCL4soZ+jX254gSOn64I5dVjxYMdYMfTTnEwYuujSoUqSkH9pGGAMCl6hSMszc2VlnzxWGPRDhtibGSLqK3+b5KKbj6b2db7k2LwxldRYCt62ZEqTeo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729158992; c=relaxed/simple; bh=4q66nhbhtRB2E2NWPNRJ6n4igTeASGKwvtYUoBPLkCs=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=d1E5hpc91s2OQ5WgbO7+dlmIT5BFt5Dru6MUaIUDVrrJFEzYRstqDv+f5YV0c0XDoRZayz18XQEjtwMUOF6GhJoc+Gv/VNBzGIHJ+hRWNcgY6v+blCauP6x8p5aNzTOEGrHmhMQmOo8+6a4cndsrW+ITRI8YeACrSX3QA7B7UFE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vAFJ6PAI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vAFJ6PAI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 814A1C4CEC5; Thu, 17 Oct 2024 09:56:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729158991; bh=4q66nhbhtRB2E2NWPNRJ6n4igTeASGKwvtYUoBPLkCs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vAFJ6PAIGpwErAX/6NNQIHWUCUhm6OCqIHrt1+rH0SEBETrbQLcj4QNyXuuRnLaVd d3Q9bk69Akh1f1w3FJCbAvAQHMt33cW15OjODfTYU0n+KqIh4VuyQKDN6BSvUpFquQ ok475/xZzE8OpDu3onODRouQJzqQ94Y8aY8X+gQcw+ql2LUFaFru/kxLyZ4aG2bZd9 oA2xCZOsEu6ktNlN1kK2M690N7dvcW7Wnp08ia4dumEsMLme3vkOSh7+T49SdqKoc2 YZXzHLcvCgn5hJ9dz9fTQy82TtrQsuJFBSve0sqx3gxhH4NZE2tOIu5773TsGVTWRd L44+77Ir7Dcgw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1t1NF7-004PBo-Ck; Thu, 17 Oct 2024 10:56:29 +0100 Date: Thu, 17 Oct 2024 10:56:29 +0100 Message-ID: <86o73j3vea.wl-maz@kernel.org> From: Marc Zyngier To: Manivannan Sadhasivam Cc: Johan Hovold , Bjorn Helgaas , Pali =?UTF-8?B?Um9ow6Fy?= , Johan Hovold , Kishon Vijay Abraham I , Xiaowei Song , Binghui Wang , Thierry Reding , Ryder Lee , Jianjun Wang , linux-pci@vger.kernel.org, Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Ley Foon Tan , linux-kernel@vger.kernel.org Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented? In-Reply-To: <20241017093040.k6pefhmfdmw4nicz@thinkpad> References: <20220727195716.GA220011@bhelgaas> <20241017052335.iue4jhvk5q4efigv@thinkpad> <86v7xr418s.wl-maz@kernel.org> <20241017082526.ppoz7ynxas5nlht5@thinkpad> <86r08f3yj1.wl-maz@kernel.org> <20241017093040.k6pefhmfdmw4nicz@thinkpad> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: manivannan.sadhasivam@linaro.org, johan@kernel.org, helgaas@kernel.org, pali@kernel.org, johan+linaro@kernel.org, kishon@ti.com, songxiaowei@hisilicon.com, wangbinghui@hisilicon.com, thierry.reding@gmail.com, ryder.lee@mediatek.com, jianjun.wang@mediatek.com, linux-pci@vger.kernel.org, kw@linux.com, ley.foon.tan@intel.com, linux-kernel@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 On Thu, 17 Oct 2024 10:30:40 +0100, Manivannan Sadhasivam wrote: > > On Thu, Oct 17, 2024 at 09:48:50AM +0100, Marc Zyngier wrote: > > On Thu, 17 Oct 2024 09:25:26 +0100, > > Manivannan Sadhasivam wrote: > > > > > > On Thu, Oct 17, 2024 at 08:50:11AM +0100, Marc Zyngier wrote: > > > > On Thu, 17 Oct 2024 06:23:35 +0100, > > > > Manivannan Sadhasivam wrote: > > > > > > > > > > So can we proceed with the series making Qcom driver modular? > > > > > > > > Who is volunteering to fix the drivers that will invariably explode > > > > once we allow this? > > > > > > > > > > Why should anyone volunteer first up? If the issue gets reported for a driver > > > blowing up, then the driver has to be fixed by the maintainer or someone, just > > > like any other bug. > > > > You are introducing a new behaviour, and decide that it is fair game > > to delegate the problems *you* introduced to someone else? > > > > You are getting it completely wrong. I'm not delegating any issues. If the so > called *new* behavior in the controller driver uncovers the bug in a client > driver, then that is not called *delegating*. > > > Maybe you should reconsider what it means to be a *responsible* > > maintainer. > > > > Sure, by not providing a development option useful to the users envisioning > issues that may not happen at all. > > Even if any issue reported for the platform I'm maintaining, I am willing to put > in the efforts to fix them. > > > > From reading the thread, the major concern was disposing the IRQs before > > > removing the domain and that is now taken care of. If you are worrying about a > > > specific issue, please say so. > > > > That concern still exists, and I haven't seen a *consistent* approach > > encompassing all of the PCI controllers. What I've seen is a bunch of > > point hacks addressing a local issue on a particular implementation. > > > > Again, please be specific about your concern so that someone could try to > address them. Right now all I'm hearing is, "hey don't do this, else > something may blow up". You know what? Have it your way. After all, this sort of behaviour is exactly why I stopped dealing with this subsystem. > > > I don't think that's the correct approach, but hey, what do I > > understand about interrupts and kernel maintenance? > > > > I'd like to quote the message in your signature here: "Without deviation from > the norm, progress is not possible". You should look up who wrote this, and appreciate *why* they wrote it, and what they meant by that. That should put some of the above in perspective. M. -- Without deviation from the norm, progress is not possible.