[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <86o73j3vea.wl-maz@kernel.org>
Date: Thu, 17 Oct 2024 10:56:29 +0100
From: Marc Zyngier <maz@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Johan Hovold <johan@...nel.org>, Bjorn Helgaas <helgaas@...nel.org>,
Pali Rohár <pali@...nel.org>, Johan Hovold
<johan+linaro@...nel.org>, Kishon Vijay Abraham I <kishon@...com>, Xiaowei
Song <songxiaowei@...ilicon.com>, Binghui Wang <wangbinghui@...ilicon.com>,
Thierry Reding <thierry.reding@...il.com>, Ryder Lee
<ryder.lee@...iatek.com>, Jianjun Wang <jianjun.wang@...iatek.com>,
linux-pci@...r.kernel.org, Krzysztof Wilczyński
<kw@...ux.com>, Ley Foon Tan <ley.foon.tan@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented?
On Thu, 17 Oct 2024 10:30:40 +0100,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> 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@...aro.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@...aro.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?
> >
>
> 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.
Powered by blists - more mailing lists