From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id C97667D910 for ; Wed, 11 Mar 2020 16:09:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729995AbgCKQJ7 (ORCPT ); Wed, 11 Mar 2020 12:09:59 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:33328 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729887AbgCKQJ7 (ORCPT ); Wed, 11 Mar 2020 12:09:59 -0400 Received: by mail-ot1-f65.google.com with SMTP id g15so2579333otr.0 for ; Wed, 11 Mar 2020 09:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qHCMeKPDxYeB8oLBoOVgW7eRt3m++jTxFNAqk0lBahg=; b=T+2qbotF8YuwXHpWLAJaVZ3hVF/dquYCSRS05M1A7mvQV5LzfewtWVTsHWdk8Go9F/ 2g/4Ym2nx7n5QV/sER4Txqu5rPTxqet8VHyUWGxCmwWAJt3qUQiSWGPET2xfNz9JfedF 5xwHqKoGb41geEImN2fUmeSQQF7St0SbGtqHlmlfn6i/7S3/hSGDeYa08lyFqq83sM5I UZp8EKZAV1mUiq5TMGDkiQlDPoljkg8PtpjL06pqruUn0UYWL7pIycT6vZrXwQHxfMFV S60j0XBqb/FAOJfDMpT+2LXN3h4M5o4PLyfEnFL6nPDVvmcVHwvYhv+3zKS43eS04L3G EiGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qHCMeKPDxYeB8oLBoOVgW7eRt3m++jTxFNAqk0lBahg=; b=OS2Bs5pODSj6BJCjA/5ru67cIzUnpDJxdlpJcN3LdczHJvHtPNV+HVj9qEU5KhUhVn t4Dh7Jo2CJDYLbUMyn6rPORKPwr4gAkOV4LlHEExZbkb0WjV+cCNRFy8cGqyheIjBkvs +b8zFNfZvyYz92F9XOIuEZUjp0xc0xznq8qRJgSyQfmLwryAnNyPjU4ZhtL4Pm0qL5yl kHccrhhaP8N79AymoIqKNlTzPYEABlCipvQsV6FoHqJlI7MkC3B+GFME5jO2CLu9rkMG 9xzwEA2WwNv1FYxwVMojX1U6kBECnptyv6jx+AGiCz5YrwC7dAeZziz9Vg8eT5qshdZA B07A== X-Gm-Message-State: ANhLgQ1Fc2mpooDp4X5nrEhP0no/OtvDTEHPMZb+BUeP/B9efMSzTo2n giK/wqrbWMGUQeGguzem9tWocPdOI8bByDsqywDKyA== X-Google-Smtp-Source: ADFU+vsF0mYOWDUY9jeerFS7C1YHWPcdcvJokSfwKoYIwMy0iUuNQO8orU7ziwk2fzKINRWEir3a59IQXixeW7y6JDo= X-Received: by 2002:a4a:2a47:: with SMTP id x7mr790140oox.23.1583942995604; Wed, 11 Mar 2020 09:09:55 -0700 (PDT) MIME-Version: 1.0 References: <20190430101230.21794-1-lokeshvutla@ti.com> <20190430101230.21794-8-lokeshvutla@ti.com> <87zhcmkicp.fsf@nanos.tec.linutronix.de> In-Reply-To: <87zhcmkicp.fsf@nanos.tec.linutronix.de> From: Tim Harvey Date: Wed, 11 Mar 2020 09:09:43 -0700 Message-ID: Subject: Re: [PATCH v8 07/14] gpio: thunderx: Use the default parent apis for {request,release}_resources To: Thomas Gleixner , Lokesh Vutla Cc: Marc Zyngier , Santosh Shilimkar , Rob Herring , Nishanth Menon , Jason Cooper , Linux ARM Mailing List , open list , Tero Kristo , Sekhar Nori , Tony Lindgren , Linus Walleij , Peter Ujfalusi , Grygorii Strashko , Device Tree Mailing List , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Archived-At: List-Archive: List-Post: On Wed, Mar 11, 2020 at 8:43 AM Thomas Gleixner wrote: > > Tim, > > Tim Harvey writes: > > On Tue, Apr 30, 2019 at 3:14 AM Lokesh Vutla 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