From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="bJ65ZEwG" Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34A0D95; Tue, 28 Nov 2023 04:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2AMt7jp7zrGQ1Hr3T3kEt4MJP2MZsgNYKWbkaVlt5lk=; b=bJ65ZEwGSH2/MC2OoHkcrz4GcS d+gmN9w5J4sSugxSmgc44OC9HhFr5Gp145bwfaOcSUcRMdonH1ZRdHT2it78kzD4P5BTf2tm7g9BY 9e5Q5zqZHhZDb6kwhBJf4X22sCAOM4qNehy+hvPCYuA8oKQR5St65HLa6xr+el5C9w5Kyx5jVii5d 5lEMPCxbd9wv6rz3A95i1PUbfBw+wDDpQTaaTsCFHqPF7TNQIZedX7f1SfAOA4Uti+qPV+px7CddW 6O9FEWcVE7w+GOiqfArHIdSwncoehFRgPuI0rqhC263cnhEfI5KEPT6JmLxZ/wBEs5AcLIKssDQxN N7yFTKTQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47282) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1r7x6V-0007HZ-2S; Tue, 28 Nov 2023 12:22:15 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1r7x6U-0002wn-Ib; Tue, 28 Nov 2023 12:22:14 +0000 Date: Tue, 28 Nov 2023 12:22:14 +0000 From: "Russell King (Oracle)" To: Christian Marangi Cc: Andrew Lunn , Florian Fainelli , Broadcom internal kernel review list , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vladimir Oltean , David Epping , Harini Katakam , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [net-next PATCH v2 3/4] net: phy: restructure __phy_write/read_mmd to helper and phydev user Message-ID: References: <20231126235141.17996-1-ansuelsmth@gmail.com> <20231126235141.17996-3-ansuelsmth@gmail.com> <6565d8d6.5d0a0220.5f8f1.b9d7@mx.google.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6565d8d6.5d0a0220.5f8f1.b9d7@mx.google.com> Sender: Russell King (Oracle) On Tue, Nov 28, 2023 at 01:11:00PM +0100, Christian Marangi wrote: > On Tue, Nov 28, 2023 at 01:46:10AM +0100, Andrew Lunn wrote: > > On Mon, Nov 27, 2023 at 12:51:40AM +0100, Christian Marangi wrote: > > > Restructure phy_write_mmd and phy_read_mmd to implement generic helper > > > for direct mdiobus access for mmd and use these helper for phydev user. > > > > > > This is needed in preparation of PHY package API that requires generic > > > access to the mdiobus and are deatched from phydev struct but instead > > > access them based on PHY package base_addr and offsets. > > > > Why is this all going into the header file? > > > > Was following the pattern done by phy_package_read/write. > > Considering those API are not single function call... I wonder if those > should be moved in phy_core.c instead of static inline them in the > header. phy_package_{read,write} are simple affairs - one test and a call to a function. That makes them fairly small. The proposed new functions aren't small, which means that we get a load of code each time they're used. Therefore, it's better that they're out of line. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!