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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0E27C432BE for ; Mon, 9 Aug 2021 11:19:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ACBE360C41 for ; Mon, 9 Aug 2021 11:19:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235042AbhHILUI (ORCPT ); Mon, 9 Aug 2021 07:20:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:52728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234657AbhHILUH (ORCPT ); Mon, 9 Aug 2021 07:20:07 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B2E0C61004; Mon, 9 Aug 2021 11:19:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628507986; bh=RQCOogQ9mJQxyDapNiOoSY73gdfpVbaZ71bUZ+LL2NA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UecVt6vx5862rMgdKPGDZ5nFaiR+XCtrI3nH+YgZsgyeEKU90IQCTUDJDcMrc5RIs rzNFq6Cr7K/UCqkqE+l8NDoZTRhcriNtyLxa8hAL4SGxKdQPJlq2ONRsiAqbdLjsGi viqiDZkMG8P3wC+M6vl0DgTScfTiMGhpxpJEXXD2IQF1cOOG9HswP2s/mQh39rPD9K Y2z9wmRMTiQg7S6NTOBfgMdXdtVY92U25PWyc21ggvb14icB25KljZbxyfmPJjgZ+5 eQSRZ12YxcYBr1udpSMl+45fFv/RcCKjwgRqLC4/nVMarGPfnZi0iGL0ZCXeFRVbI9 BQGMcor8YjzwA== Received: by mail-wm1-f44.google.com with SMTP id d131-20020a1c1d890000b02902516717f562so11246950wmd.3; Mon, 09 Aug 2021 04:19:46 -0700 (PDT) X-Gm-Message-State: AOAM532whSvAqbLHq+ULgFyvnTXXFP6aS+iX9wJx/gY9Dds7+uxO8pMH IUJyCZ5PQRFxMMs6F7qlnIAJZJhSpGfEhrBBz08= X-Google-Smtp-Source: ABdhPJy/gQFqWtKPTewnQcS4i0Qy8/1Qz0/EDjK/S5Yypcd1Jcj8yNomlxp6WiiR0A3m4+JYUiJaXCS6t1ZWV4FzDA0= X-Received: by 2002:a7b:ce10:: with SMTP id m16mr32350595wmc.75.1628507985226; Mon, 09 Aug 2021 04:19:45 -0700 (PDT) MIME-Version: 1.0 References: <75c8e6e5e8dfa1889938f3a6b2d991763c7a3717.1627989586.git.viresh.kumar@linaro.org> <0100017b1610f711-c53c79f2-9e28-4c45-bb42-8db09688b18e-000000@email.amazonses.com> <20210805124922.j7lts7tfmm4t2kpf@vireshk-i7> <0100017b1a6c0a05-e41dc16c-b326-4017-a63d-a24a6c1fde70-000000@email.amazonses.com> <20210809073020.y6ruibdm37xnx7hg@vireshk-i7> <0100017b2a85eaf8-08b905fc-89f7-43a4-857e-070ca9691ce1-000000@email.amazonses.com> In-Reply-To: <0100017b2a85eaf8-08b905fc-89f7-43a4-857e-070ca9691ce1-000000@email.amazonses.com> From: Arnd Bergmann Date: Mon, 9 Aug 2021 13:19:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Stratos-dev] [PATCH V4 2/2] gpio: virtio: Add IRQ support To: Viresh Kumar Cc: "Michael S. Tsirkin" , Viresh Kumar , Linus Walleij , Cornelia Huck , Linux Kernel Mailing List , "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" , Bartosz Golaszewski , Geert Uytterhoeven , "open list:GPIO SUBSYSTEM" , Marc Zyngier , Thomas Gleixner , "Enrico Weigelt, metux IT consult" , Jason Wang , Stratos Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 9, 2021 at 12:47 PM Viresh Kumar via Stratos-dev wrote: > > On 09-08-21, 09:55, Arnd Bergmann wrote: > > Ah, right. There is already a flag that gets checked by the caller. > > > > It does feel odd to have an empty 'irq_mask' callback though, so > > maybe there is still something missing, just not what I thought. > > > > It's probably the result of calling handle_level_irq(), which as you > > said is closer to what we want, but is not exactly what we need for > > this protocol. > > Okay, I have tried to take care of locking as well now and used local > flags only to make sure I can depend on them to get the locking > working properly. Lets see what's broken in this now :) I don't see anything wrong with this version, but let's see what Marc thinks. I expect that he can still poke some holes in it, or at least find some simplifications. I was slightly surprised at the relation between the disabled and masked states, where 'disable' always implies 'mask' and 'enable' always implies 'unmask', but I don't actually know how those two are actually defined in the irqchip code in Linux, so I assume you did this correctly. Arnd