Re: Why set .suppress_bind_attrs even though .remove() implemented?

[Marc Zyngier <maz@kernel.org>]

On Thu, 17 Oct 2024 09:25:26 +0100,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> 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@linaro.org> 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.