On Thu, 17 Oct 2024 10:30:40 +0100, Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> 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 <manivannan.sadhasivam@xxxxxxxxxx> 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 <manivannan.sadhasivam@xxxxxxxxxx> 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.
