Re: [PATCH] PCI: mvebu: Use devm_request_irq() for registering interrupt handler

[Lorenzo Pieralisi]

On Fri, Nov 11, 2022 at 06:15:14PM +0100, Pali Rohár wrote:

[...]

> > > So, could you then propose a solution how to fix this issue to allow one
> > > interrupt to be shared with more devices, like it is needed for some
> > > Armada platforms? Because I do not see a way how to do it without
> > > IRQF_SHARED and without shared interrupt it is not possible to implement
> > > any other pending features.
> > > 
> > > I'm feeling that since May there is just conclusion that all development
> > > on the mvebu must be stopped as more people here do not like this
> > > hardware and trying to do remove it or at least make it orphan.
> > 
> > Marc gave you a solution - we are going round in circles, it is getting
> > boring, honestly.
> > 
> > https://lore.kernel.org/linux-pci/874k0bf7f7.wl-maz@xxxxxxxxxx
> 
> This is not the solution. As this does not allow to share one interrupt
> by multiple devices / drivers, like devm_request_irq with IRQF_SHARED
> flag. irq_set_chained_handler_and_data() can be used only by one device.
> This was expressed more times in other threads, but seems it was
> ignored.
> 
> In past I have already send patches for armada interrupt drivers and
> they were rejected by Marc, who did not wanted to talk about them. And
> in past already expressed that he is not interested in any more
> development in Armada HW as by thinks it is broken hardware and his
> devel board stopped working.
> 
> I'm really not going to implement anything new for people who already
> expressed that would reject my contribution. Why would I do it?

Because that's the only way you can get this done, that's how it works,
I can't merge code that the respective maintainer finds unacceptable.

> Anyway, here we are dealing with REGRESSION in mainline kernel. Not a
> new feature. Mainline kernel is currently broken and this my patch is
> fixing it. Exactly same fix was already applied for other pci controller
> driver.
> 
> Why it is disallowed to fix regression in kernel with exactly same
> approach and same patch which was allowed for other drivers? Because it
> really looks like that somebody is trying to ensure that Linux kernel
> should stop working on existing hardware.

Your impression is wrong - please reconsider it. The goal is to remove
the unacceptable code from the kernel not adding to it to create even
more broken legacy. It is not against this patch or HW, it is against
this same code that there is pushback, there are no strings attached.

> > Either you implement what he asks for or I drop this patch and all
> > dependent ones from the PCI queue - apologies.
> > 
> > Lorenzo
> 
> So, please if you are going to drop patch series, and you do not like my
> fix for mentioned issue, could you please fix the driver to work in
> mainline kernel?

It is not that I don't like it, I expressed the reason why I can't merge
it above.

I can't fix it for you.

> Do not take me wrong, but it is really problem if mainline kernel is
> broken, developers like Greg are publicly talking that vendors,
> distributors and other should update kernels to new versions and not
> stay on the old one; and then other developers are rejecting fixes to
> regression in new versions and basically are saying that people and
> vendors should not upgrade kernels to new versions as it would stop
> working on some hardware.
> 
> And I'm not even mentioned that there happened lot of other development
> and cleanup in this area and everything is stopped and maybe now after
> 2 years would discarded, like some developers want as they do not like
> some kind of hardware.

See above, let's close this argument.

> I'm really disappointed that I have to discuss about such thing.

So am I :)

> If fixing regressions and bugs is not a priority for kernel and is first
> subject to rewrite other parts of code and implement couple of new
> features, then I think it is a good idea to stop being doing
> development.

Don't twist it that way, I think we have been clear on the matter.

Lorenzo