Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4030177pxb; Mon, 27 Sep 2021 07:58:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRiGeSsE6FEPAkKYbepMFzvcTAEFJu8wTMqMcC5qxjREcgPtJYfBAgydzknFSrQDeuFsBz X-Received: by 2002:a17:902:d797:b0:13e:3d17:8ddb with SMTP id z23-20020a170902d79700b0013e3d178ddbmr241643ply.88.1632754739498; Mon, 27 Sep 2021 07:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632754739; cv=none; d=google.com; s=arc-20160816; b=ac8xqZG3c1vJ2aiOnnlWueLpw1QgFg9jbyhj16mKLZFYGEkzSPWOD8f9h/9oaeaoVj Co0iEnqfH+JBx7wu/X61fxUPFbs56QUwftgZ5kby0RUwvK6Hv3PG3HT7YL03l8oGjvdw LcVTg7tIj1kXcz6DJ3m+LNotg76T2MIg7uTNAsXUmIGoCSq/ESRG5VOrbWOxN82LXliJ 5yK9SibyB0qMyL/AR6oz//ved6Z9mu5ufbWAX32KG0Jak9VHqtAICkkPQ8KhV59A8iM7 qAgRK/gktSEKLvjHMQbm7hrdgKZ4jh4zsR32rzN1QP3lsg4NHtWme6xfj14R2dxJRW2Y eAcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=OSZSvQFG7O4SxG9se9x14daH7zm+W8BUgPWCOS3jbis=; b=e2jIE0QcACj6jkCb14eSSl2KipW0F00ydk64eFJeGn5wunqtXQICcGhR3A5xg8sr4M 6633NDcSN9195GCLkfk7OoeHttcN1iD/BUIa/ZFOAkQuri3tYhRvTc66CAHFayIfjHH8 1L1VIhki5IYcBQmSWh+4SE+C199RarvdtKAkzoEc05kCcywY77nru2kdt3Hv9KQ2pGXT xL95jbYfK8YwHgYN2T3isrlG3orqw/raPyhmS0MLtK7crgWEyONN6LdvbxkphXoA84Vf ljlQW8lOC0G5echKx1jFsWCQq9pj76yi+dBfZ/IFa8hptnpA+lQUHUH14EE8VW6JvVrc 6Hkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=b3ok4Sdm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gi1si20707509pjb.187.2021.09.27.07.58.46; Mon, 27 Sep 2021 07:58:59 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=b3ok4Sdm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234922AbhI0O6R (ORCPT + 99 others); Mon, 27 Sep 2021 10:58:17 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:33900 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234782AbhI0O6Q (ORCPT ); Mon, 27 Sep 2021 10:58:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=OSZSvQFG7O4SxG9se9x14daH7zm+W8BUgPWCOS3jbis=; b=b3ok4SdmPhMIWP3Ea5yrSayVu6 Z5GxVANQjdNDET/0Z0Oa54t+a8v88c1WMeFGSpgVM6Mp578phmrN8mDsHwJDgdze8PZLSWLd5u7LD yjBA+YGCgLqmWmXjAYOy0wuA4cU3sg5iRKLEHVfEkzP/xknYrh/FpHM2/mlog6a1amZw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mUs3X-008S9d-7N; Mon, 27 Sep 2021 16:56:35 +0200 Date: Mon, 27 Sep 2021 16:56:35 +0200 From: Andrew Lunn To: Asmaa Mnebhi Cc: Linus Walleij , Andy Shevchenko , "open list:GPIO SUBSYSTEM" , netdev , linux-kernel , ACPI Devel Maling List , Jakub Kicinski , Bartosz Golaszewski , "David S. Miller" , "Rafael J. Wysocki" , David Thompson Subject: Re: [PATCH v3 1/2] gpio: mlxbf2: Introduce IRQ support Message-ID: References: <20210923202216.16091-1-asmaa@nvidia.com> <20210923202216.16091-2-asmaa@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 27, 2021 at 02:19:45PM +0000, Asmaa Mnebhi wrote: > > > The BlueField GPIO HW only support Edge interrupts. > > O.K. So please remove all level support from this driver, > and return -EINVAL if requested to do level. > This also means, you cannot use interrupts with the > Ethernet PHY. The PHY is using level interrupts. > > Why not? The HW folks said it is alright because they > Do some internal conversion of PHY signal and we have tested > This extensively. So the PHY is level based. The PHY is combing multiple interrupt sources into one external interrupt. If any of those internal interrupt sources are active, the external interrupt is active. If there are multiple active sources at once, the interrupt stays low, until they are all cleared. This means there is not an edge per interrupt. There is one edge when the first internal source occurs, and no more edges, even if there are more internal interrupts. The general flow in the PHY interrupt handler is to read the interrupt status register, which tells you which internal interrupts have fired. You then address these internal interrupts one by one. This can take some time, MDIO is a slow bus etc. While handling these interrupt sources, it could be another internal interrupt source triggers. This new internal interrupt source keeps the external interrupt active. But there has not been an edge, since the interrupt handler is still clearing the sources which caused the first interrupt. With level interrupts, this is not an issue. When the interrupt handler exits, the interrupt is re-enabled. Since it is still active, due to the unhandled internal interrupt sources, the level interrupt immediately fires again. the handler then sees this new interrupt and handles it. At that point the level interrupt goes inactive. Now think about what happens if you are using an edge interrupt controller with a level interrupt. You get the first edge, and call the interrupt handler. And then there are no more edges, despite there being more interrupts. You not only loose the new interrupt, you never see any more interrupts. You PHY link can go up and down, it can try to report being over temperature, that it has detected power from the peer, cable tests have passed, etc. But since there is no edge, there is never an interrupt. So you say it has been extensively tested. Has it been extensively tested with multiple internal interrupt sources at the same time? And with slight timing variations, so that you trigger this race condition? It is not going to happen very often, but when it does, it is going to be very bad. Andrew