On Wed, Nov 03, 2021 at 01:35:23PM +0100, Emil Renner Berthing wrote:

On Wed, 3 Nov 2021 at 10:13, Andy Shevchenko [off-list ref] wrote:

quoted

On Tue, Nov 2, 2021 at 10:35 PM Emil Renner Berthing [off-list ref] wrote:

quoted

On Tue, 2 Nov 2021 at 21:02, Andy Shevchenko [off-list ref] wrote:

quoted

On Tue, Nov 2, 2021 at 6:50 PM Emil Renner Berthing [off-list ref] wrote:

...

quoted

quoted

quoted

quoted

+               irq_set_handler_locked(d, handle_bad_irq);

Why? You have it already in ->probe(), what's the point?

So last time you asked about this, I explained a situation where
userspace first grabs a GPIO, set the interrupt to edge triggered, and
then later loads a driver that requests an unsupported IRQ type.

I didn't get this scenario. Is it real?

No, it's totally made up, but I mean we even have tools like fuzzing
to help us find bugs that would never happen in real use cases.

quoted

quoted

Then
I'd like to set the handler back to handle_bad_irq so we don't get
weird interrupts, but maybe now you know a reason why that doesn't
matter or can't happen?

In ->probe() you set _default_ handler to bad(), what do you mean by
'set the handler back to bad()'? How is it otherwise if you free an
interrupt?

It might not be, but when not sure I thought it better to error on the
safe side.

With a dead code?

I do not believe there is an issue since. like I said, there are plenty drivers
that don't do what you are suggesting here --> 99.99% you added a dead code.

quoted

So, please elaborate with call traces what the scenario / use case you
are talking about. If it's true what you are saying, we have a
situation (plenty of GPIO drivers don't do what you are suggesting
here).

-- 
With Best Regards,
Andy Shevchenko