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;
From:   Asmaa Mnebhi <asmaa@nvidia.com>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     Linus Walleij <linus.walleij@linaro.org>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Jakub Kicinski <kuba@kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        "David S. Miller" <davem@davemloft.net>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        David Thompson <davthompson@nvidia.com>
Subject: RE: [PATCH v3 1/2] gpio: mlxbf2: Introduce IRQ support
Thread-Topic: [PATCH v3 1/2] gpio: mlxbf2: Introduce IRQ support
Thread-Index: AQHXsLi5/ezHFM2t80qMnoiP1wWjOauzEi0AgADJmACABBI7EIAAAriAgAACbtCAAAsjgIABjviQ
Date:   Tue, 28 Sep 2021 15:02:02 +0000
Message-ID: <CH2PR12MB389530F4A65840FE04DC8628D7A89@CH2PR12MB3895.namprd12.prod.outlook.com>
References: <20210923202216.16091-1-asmaa@nvidia.com>
 <20210923202216.16091-2-asmaa@nvidia.com> <YU26lIUayYXU/x9l@lunn.ch>
 <CACRpkdbUJF6VUPk9kCMPBvjeL3frJAbHq+h0-z7P-a1pSU+fiw@mail.gmail.com>
 <CH2PR12MB38951F2326196AB5B573A73DD7A79@CH2PR12MB3895.namprd12.prod.outlook.com>
 <YVHQQcv2M6soJR6u@lunn.ch>
 <CH2PR12MB389585F7D5EFE5E2453593DBD7A79@CH2PR12MB3895.namprd12.prod.outlook.com>
 <YVHbo/cJcHzxUk+d@lunn.ch>
In-Reply-To: <YVHbo/cJcHzxUk+d@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+7PLm79hvOGPtGC3ThZExJR4LYiVed1Uxbv+PeNwforLJ7DDYbyCRjdNY3J0?=
 =?us-ascii?Q?TxWT5iS+uljVP6J5YL38VoXDY9rwW11F1FXCj4Y11JxFnJ0kM1+lh2qrPH8d?=
 =?us-ascii?Q?+taB8trdGllpNc6W3IxMKMe1pABgdKM6mea9iTg88g0fkhL7X3dpvYJP1Pfl?=
 =?us-ascii?Q?D3b4aXjARzAPCVjZI9x9xjxzWqs3xushBpBqZJTH+fsjYlzOLrI+RhL+Aif7?=
 =?us-ascii?Q?Fixmoue1lNgo85BTlJ73XOHDGkBdD+npnVJdrewTng2i011a/hv1B+QKzRRe?=
 =?us-ascii?Q?LZJLcmix+yk7VKvYr4rDKxCEJkhnLuHfwHAP63xbsP0CigBDyNKBE0IkIOSQ?=
 =?us-ascii?Q?5y4sA+Kp3I2Vqk1yrZqyrNUYVIoiZt37TJ1ICUHRRUcO0luhRmaF9cc+MBLq?=
 =?us-ascii?Q?ztYWM5KAMEc/NTKdIeM1HNQ3PGXM2cdbUawzJaa4wkO88VAqrFYrvmTFyR6J?=
 =?us-ascii?Q?QHfIoCrZqGtJAzzUWiLPTR7HQz12P8F7aaYrHmneEFJRacodPafeGo4kRnW0?=
 =?us-ascii?Q?OYxDKL1VCBFV0y/u/hMLxyEXEAkNTum+dUBDokUYlEVSu0fSrMnaDVDbOJfm?=
 =?us-ascii?Q?vvf2eablr9LNcBHavFSlOzTO9IwWLE24rdCSQE/j/KJzhuyrSBq82Qvp8SZO?=
 =?us-ascii?Q?TJbxJwGN+9xJaXh9Dn3fHDxjzK+iRehy+CXHWnFegGObtuvCKZStxtrfGlo/?=
 =?us-ascii?Q?9qts8P4S1q9xUxLcUEg5uPXF98fCoDWwHBXvp8A/k0TG3DUVsgLpnaa8z4xf?=
 =?us-ascii?Q?z3eDpEwuSb7kK4NOZ8/CQXRCvnohJFbA7hkH8SwOJrLSxa0VDN6mn6BT85dD?=
 =?us-ascii?Q?ixpsn+/gKhQxJsqwJkpT841GqNjM3UsDeBzzpPMTnGXtKP/oiE0Mj2CoPFEz?=
 =?us-ascii?Q?ppY1cEOpnLkqmz2jIV+I1pbLAIYHjXHi1nEIuHeRBQAxxncC30x+VTDCZ/zC?=
 =?us-ascii?Q?x4lqtmwMLz/pYoYN4m2dE95ekGuQg8j7VaTSpu8PFNRzyPxJOC+l4MoTmp98?=
 =?us-ascii?Q?paZDG5NnSq7nA3Wii/r5W9Za09xTU4c/5EGdfWdIKWY7tqgSY2k5kjvHlwNm?=
 =?us-ascii?Q?HP7hyX8uHk8WKspnkHYg12lRPLR13UQEZe1S2bahkwVHSO65J2GujvnkILou?=
 =?us-ascii?Q?x4j/UyMOgxYpzrMAWaADtRsWTuGpGSW+/q4dUhoic2XIZIYtrsi/hIp3hD7r?=
 =?us-ascii?Q?qm6veatCo0OPS8dnxcgJNhTzls5DdmKlLBrkxzm9K5dnKT2OrBkClDGXMBo/?=
 =?us-ascii?Q?DCCmT/qxJB2JPRxUZBc3AAUQMCkNGGTYaVPHSolrg8yg3ZBZ1X5SZK7kX2ec?=
 =?us-ascii?Q?I+pELnoIGPME0b70ZxbPKcZ0?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB3895.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c27ebbb1-85cf-4da1-ee0f-08d98290ee0f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2021 15:02:02.9829
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZY2qjAT4VsnQvHdto9uJ+146gLLfvoAY04MBDSpvg0fk76Via7nRcdu0WdyU6tUupuImR8uZ/gXyh/n6ixaFtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4263
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> So the PHY is level based. The PHY is combing multiple interrupt sources=
=20
> into one external interrupt. If any of those internal interrupt sources a=
re
> 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 inte=
rnal
> source occurs, and no more edges, > even if there are more internal inter=
rupts.

> The general flow in the PHY interrupt handler is to read the interrupt st=
atus
> register, which tells you which internal interrupts have fired. You then
> address these internal interrupts one by one.

In KSZ9031, Register MII_KSZPHY_INTCS=3D0x1B reports all interrupt events a=
nd
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 go=
od.
The code flow in our case would look like this:
- 2 interrupt sources (for example, link down followed by link up) set in M=
II_KSZPHY_INTCS
- interrupt handler (phy_interrupt) reads MII_KSZPHY_INT which automaticall=
y clears both
interrupts
- another internal source triggers and sets the register.
- The second edge will be caught accordingly by the GPIO.

> This can take some time, MDIO is a slow bus etc. While handling these int=
errupt 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, sinc=
e the interrupt=20
> handler is still clearing the sources which caused the first interrupt. W=
ith 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 lev=
el interrupt
> immediately fires again. the handler then sees this new interrupt and han=
dles it.
> At that point the level interrupt goes inactive.