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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 236B5CCA47B for ; Mon, 6 Jun 2022 01:28:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351951AbiFFB2q (ORCPT ); Sun, 5 Jun 2022 21:28:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348931AbiFFB2p (ORCPT ); Sun, 5 Jun 2022 21:28:45 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E94B36562; Sun, 5 Jun 2022 18:28:43 -0700 (PDT) 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=v2/b5FqxV2iRhS1Ykan9Lwjt+zRuUcpsfnrGF+r1rwo=; b=ahtDNE/A9/2Pzy2ITsWjUxwbex 4iUrMeJfGWfXjeG0gSwGcbTtXtdOX4F2c8Nkv9fpscSwVzdT0JJl1Vg9UdaHn5+hXcDItYdoyxiey +QvwzIs4ulACjTMF0Fk+1kJBPDCITFsirVPIQVkeZf/KsgEJIHD8RXT2IOPfkZFxQ5es=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1ny1XL-005hL6-Hk; Mon, 06 Jun 2022 03:28:07 +0200 Date: Mon, 6 Jun 2022 03:28:07 +0200 From: Andrew Lunn To: Lukas Wunner Cc: Marek Szyprowski , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , netdev@vger.kernel.org, linux-usb@vger.kernel.org, Steve Glendinning , UNGLinuxDriver@microchip.com, Oliver Neukum , Andre Edich , Oleksij Rempel , Martyn Welch , Gabriel Hojda , Christoph Fritz , Lino Sanfilippo , Philipp Rosenberger , Heiner Kallweit , Russell King , Ferry Toth , Krzysztof Kozlowski , 'Linux Samsung SOC' Subject: Re: [PATCH net-next v3 5/7] usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling Message-ID: References: <748ac44eeb97b209f66182f3788d2a49d7bc28fe.1652343655.git.lukas@wunner.de> <20220519190841.GA30869@wunner.de> <31baa38c-b2c7-10cd-e9cd-eee140f01788@samsung.com> <20220523094343.GA7237@wunner.de> <20220524121341.GA10702@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220524121341.GA10702@wunner.de> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > mdio_bus_phy_resume() does trigger the state machine via > phy_start_machine(), so link state changes *are* detected after wakeup. > > But you're saying that's not sufficient and you really want the > PHY driver's IRQ handler to be called, do I understand that correctly? It is an interrupt, so i would expect the handler to be called. I've never looked deeply how the kernel handles this, but maybe there is some core support for this. The kernel does know about wake up interrupts. The interesting bit is how do you defer the interrupt until you have enough of the system running again you can actually service the interrupt. PHY interrupts mostly are level, not edge, because there are multiple sources of interrupts within the PHY. So you do need to clear the interrupt source, or you are going to get a storm, as you pointed out. But being a level might actually help you. It fires once to get you out of sleep, and then fires again when the interrupt controller is resumed and is enabled. Andrew