On Wed, Mar 11, 2020 at 8:43 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> Tim,
>
> Tim Harvey <tharvey@xxxxxxxxxxxxx> writes:
> > On Tue, Apr 30, 2019 at 3:14 AM Lokesh Vutla <lokeshvutla@xxxxxx> wrote:
> >> - if (parent_data && parent_data->chip->irq_request_resources) {
> >> - r = parent_data->chip->irq_request_resources(parent_data);
> >> - if (r)
> >> - goto error;
> >> - }
> >> + r = irq_chip_request_resources_parent(data);
> >> + if (r)
> >> + gpiochip_unlock_as_irq(&txgpio->chip, txline->line);
> >
> > This patch breaks irq resources for thunderx-gpio as
> > parent_data->chip->irq_request_resources is undefined thus your new
> > irq_chip_request_resources_parent() returns -ENOSYS causing this
> > function to return an error where as before it would happily return 0.
> >
> > Is the following the correct fix or should we qualify
> > data->parent_data->chip->irq_request_resources before calling
> > irq_chip_request_resources_parent() in thunderx-gpio?
>
> You are not supposed to fiddle with parent data at all. Just because C
> allows you is no excuse to violate abstractions in the first place.
>
> irq_chip_request_resources_parent() rightfully returns -ENOSYS when it
> can't request a resource from the parent chip because that chip does not
> have anything to offer.
>
> It's up to the caller to do something sensible with the return code. If
> your chip is happy with the parent not providing it then handle
> -ENOSYS. None of the chip callbacks should return -ENOSYS. If one does
> then that wants to be fixed.
>
Ok, makes sense. Thank you and Lokesh for the feedback. I just
submitted a patch to fix the thunderx-gpio breakage.
Best Regards,
Tim
