Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 16 Sep 2021 19:34:20 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Asmaa Mnebhi <asmaa@nvidia.com>
Cc:     "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        David Thompson <davthompson@nvidia.com>
Subject: Re: [PATCH v1 1/2] gpio: mlxbf2: Introduce IRQ support
Message-ID: <YUOAHMmaSf2gs6ho@lunn.ch>
References: <20210915222847.10239-1-asmaa@nvidia.com>
 <20210915222847.10239-2-asmaa@nvidia.com>
 <YUNPO9/YacBNr/yQ@lunn.ch>
 <CH2PR12MB3895D5E16EAA1D3E5796C177D7DC9@CH2PR12MB3895.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CH2PR12MB3895D5E16EAA1D3E5796C177D7DC9@CH2PR12MB3895.namprd12.prod.outlook.com>
Precedence: bulk

On Thu, Sep 16, 2021 at 03:48:51PM +0000, Asmaa Mnebhi wrote:
> > +	/* Enable PHY interrupt by setting the priority level */
> 
> This should be an abstract driver for a collection of GPIO lines.
> Yes, one of these GPIOs is used for the PHY, but the GPIO driver does not care. So please remove this comment.
> Asmaa>> Done
> 
> > +	val = readl(gs->gpio_io + YU_GPIO_CAUSE_OR_EVTEN0);
> > +	val |= BIT(offset);
> > +	writel(val, gs->gpio_io + YU_GPIO_CAUSE_OR_EVTEN0);
> 
> What exactly does this do? It appears to clear the interrupt, if i understand mlxbf2_gpio_irq_handler(). I don't know the GPIO framework well enough to know if this is correct. It does mean if the interrupt signal is active but masked, and you enable it, you appear to loose the interrupt? Maybe you want the interrupt to fire as soon as it is enabled?
> 
> Asmaa>>
> YU_GPIO_CAUSE_OR_CLRCAUSE - Makes sure the interrupt is initially cleared. Otherwise, we will not receive further interrupts.

If the interrupt status bit is set, as soon as you unmask the
interrupt, the hardware should fire the interrupt. At least, that is
how interrupt controllers usually work.

A typical pattern is that the interrupt fires. You mask it, ack it,
and then do what is needed to actually handle the interrupt. While
doing the handling, the hardware can indicate the interrupt again. But
since it is masked nothing happened. This avoids your interrupt handler
going recursive. Once the handler has finished, the interrupt is
unmasked. At this point it actually fires, triggering the interrupt
handler again.

Please also get your email client fixed. I wrap my emails at around 75
characters. Your mailer has destroyed it. Your text should also be
wrapped at about 75 characters.

	Andrew