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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82D00C433EF for ; Wed, 29 Sep 2021 20:24:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6780561462 for ; Wed, 29 Sep 2021 20:24:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346506AbhI2U0d (ORCPT ); Wed, 29 Sep 2021 16:26:33 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:39554 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346361AbhI2U0d (ORCPT ); Wed, 29 Sep 2021 16:26:33 -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=Lh+F5ZjCx0bOA0ZJvvdGRxDGTO4CVU+5ejZ1orJFARo=; b=MUWnnwDTA13YTmHBToqcVGDNT5 ePCd5dqFdM8DbuueNSvx9nvtXef2xRllw5xAQodxwVgSP22IWwn95jfAu9MY5mjXm9tczXEM+7wi5 fLdgN9nLR2ly4pwjSQgu4+siBw1mWaxFZfmDlbTr8cBJQkGWuVNAcjPhvYO8ya8Hc7oQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mVg8E-008qF0-Kf; Wed, 29 Sep 2021 22:24:46 +0200 Date: Wed, 29 Sep 2021 22:24:46 +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-acpi@vger.kernel.org > In KSZ9031, Register MII_KSZPHY_INTCS=0x1B reports all interrupt events and > clear on read. So if there are 4 different interrupts, once it is read once, all 4 clear at once. > The micrel.c driver has defined ack_interrupt to read the above reg and is called every time the > interrupt handler phy_interrupt is called. So in this case, we should be good. > The code flow in our case would look like this: > - 2 interrupt sources (for example, link down followed by link up) set in MII_KSZPHY_INTCS > - interrupt handler (phy_interrupt) reads MII_KSZPHY_INT which automatically clears both > interrupts > - another internal source triggers and sets the register. > - The second edge will be caught accordingly by the GPIO. I still think there is a small race window. You product manager needs to decide if that is acceptable, or if you should poll the PHY. Anyway, it is clear the hardware only does level interrupts, so the GPIO driver should only accept level interrupts. -EINVAL otherwise. I also assume you have a ACPI blob which indicates what sort of interrupts that should be used, level low, falling edge etc. Since that is outside of the kernel, i will never know what you decide to put there. Ideally, until the hardware is fixed, you should not list any interrupt and fallback to polling. Andrew