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? Maybe you should reconsider what it means to be a *responsible* maintainer. > 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. I don't think that's the correct approach, but hey, what do I understand about interrupts and kernel maintenance? > > As a Qcom PCIe driver maintainer, I'd like to provide users/developers the > flexibility to remove the driver for development purposes. Sure, whatever. M. -- Without deviation from the norm, progress is not possible.
