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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 551D5C021B8 for ; Wed, 26 Feb 2025 15:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id: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-Owner; bh=4Ozf+7Q+exXjohkxtJs5vNdrBo5Sdnc0Ag2Lz0YxhzU=; b=13xQ3n+oubA15lk/CNsaWwpQDF svS5fFEswMAj+/B17qkLXB2vevHwsz/HXWXqjOfxMNoYupC/ixVLnYWFmuBboNrQc5ipN3SMVqOge sH7dBcBBlm+Vmb4xUUvpjDZyFT9xC5H4K/TYK/KAsX2ELaLtAetsA6XwH46MF9SyZ+RIgrBHYS0DM QaSiegQ+iJX0yImrggwvRhl4zgQB9FMvrQ1oGbS1UNiGiEXLLLdR/u+Ms8diOdf7VIudPgRMsKnXe wHOGkwwNvCO2PGsb09pwjonYNN3GDMQoYs23RZEFzJ7aikkJn6E/YORnEPLUCyL1fullsyMIHf5TJ XZuY82BQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tnJEi-00000004FCQ-3liQ; Wed, 26 Feb 2025 15:22:12 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tnHQz-00000003sG1-2Lb6; Wed, 26 Feb 2025 13:26:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4Ozf+7Q+exXjohkxtJs5vNdrBo5Sdnc0Ag2Lz0YxhzU=; b=eV9qskFPoKZwRN+6N9JVTjm8Q3 FxkH4U7nFEa/cppjdADbfqmE5BAWWrEBgfpAn2clA45USjUaq+7Zj7y57DZMJ1NdZHm4ZsnnXhusu eHeZE0k0jV8c9girbgPy0GgkwvO3vJbemnADb8tV3EqrwD91w+qUgZWPC5bCwn5Rt5OOEH1p/Xxfj +gQSDljgywYEBC6cE5/rxrEzWHH2mRGjGQvH+AOGfoYqz55k1+vuTTYK0MNe3v+I5BrmNLFQKA2K0 yr2SVts4CZMDs0D9zAo9jCwTTr11aO6D5iMGrP54fFPwTj0ZNvu/ni61/oZTMpJfZAyiEIvdxSG8z QNP3OjLg==; Received: from vps0.lunn.ch ([156.67.10.101]) by casper.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tnHQw-0000000FPiQ-0uoK; Wed, 26 Feb 2025 13:26:44 +0000 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=4Ozf+7Q+exXjohkxtJs5vNdrBo5Sdnc0Ag2Lz0YxhzU=; b=M+EF2Q0a0WRuAPx96YN4gdGAGD cJUEFVSoVUXpcau6Rel+vg9J8OcLm3W6FCG3VX49WlwcmMK+wDwM5029xr9hVdseTQlMBv03A/9c6 Ra8Y8UvoFAx2/26RJRc/TNFA4IE7Sv4X42AgVaTgv8D9VZm6l33vh2vPiIqBo8ug1Skg=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1tnHQW-000GS9-6o; Wed, 26 Feb 2025 14:26:16 +0100 Date: Wed, 26 Feb 2025 14:26:16 +0100 From: Andrew Lunn To: SkyLake Huang =?utf-8?B?KOm7g+WVn+a+pCk=?= Cc: Steven Liu =?utf-8?B?KOWKieS6uuixqik=?= , "dqfext@gmail.com" , "davem@davemloft.net" , AngeloGioacchino Del Regno , "linux-kernel@vger.kernel.org" , "edumazet@google.com" , "pabeni@redhat.com" , "linux-mediatek@lists.infradead.org" , "linux@armlinux.org.uk" , "hkallweit1@gmail.com" , "horms@kernel.org" , "kuba@kernel.org" , "daniel@makrotopia.org" , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , "matthias.bgg@gmail.com" Subject: Re: [PATCH net-next v2 1/3] net: phy: mediatek: Add 2.5Gphy firmware dt-bindings and dts node Message-ID: <8bc68f1a-5abd-478c-9b9d-2c8baa6bb36a@lunn.ch> References: <20250219083910.2255981-1-SkyLake.Huang@mediatek.com> <20250219083910.2255981-2-SkyLake.Huang@mediatek.com> <176f8fe1-f4cf-4bbd-9aea-5f407cef8ac5@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250226_132642_282597_316AAF59 X-CRM114-Status: GOOD ( 16.00 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org > So I guess I can do the following according to the previous discussion: > 1) Reserve a memory region in mt7988.dtsi > reserved-memory { > #address-cells = <2>; > #size-celss = <2>; > ranges; > > /* 0x0f0100000~0x0f1f0024 are specific for built-in 2.5Gphy. > * In this range, it includes "PMB_FW_BASE"(0x0f100000) > * and "MCU_CSR_BASE"(0x0f0f0000) > */ > i2p5g: i2p5g@0f100000 { > reg = <0 0x0f010000 0 0x1e0024>; > no-map; > }; > }; Do you even need these? I assume this is in the IO space, not DRAM. So the kernel is not going to use it by default. That is why you need to specifically ioremap() it. > 2) Since PHYs don't use compatibles, hardcode address in mtk-2p5ge.c: > /* MTK_ prefix means that the macro is used for both MT7988 & MT7987*/ > #define MTK_2P5GPHY_PMB_FW_BASE (0x0f100000) > #define MT7988_2P5GE_PMB_FW_LEN (0x20000) > #define MT7987_2P5GE_PMB_FW_LEN (0x18000) > #define MTK_2P5GPHY_MCU_CSR_BASE (0x0f0f0000) > #define MTK_2P5GPHY_MCU_CSR_LEN (0x20) > > /* On MT7987, we separate firmware bin to 2 files and total size > * is decreased from 128KB(mediatek/mt7988/i2p5ge-phy-pmb.bin) to > * 96KB(mediatek/mt7987/i2p5ge-phy-pmb.bin)+ > * 28KB(mediatek/mt7987/i2p5ge-phy-DSPBitTb.bin) > * And i2p5ge-phy-DSPBitTb.bin will be loaded to > * MT7987_2P5GE_XBZ_PMA_RX_BASE > */ > #define MT7987_2P5GE_XBZ_PMA_RX_BASE (0x0f080000) > #define MT7987_2P5GE_XBZ_PMA_RX_LEN (0x5228) > #define MT7987_2P5GE_DSPBITTB_SIZE (0x7000) > > /* MT7987 requires these base addresses to manipulate some > * registers before loading firmware. > */ > #define MT7987_2P5GE_APB_BASE (0x11c30000) > #define MT7987_2P5GE_APB_LEN (0x9c) > #define MT7987_2P5GE_PMD_REG_BASE (0x0f010000) > #define MT7987_2P5GE_PMD_REG_LEN (0x210) > #define MT7987_2P5GE_XBZ_PCS_REG_BASE (0x0f030000) > #define MT7987_2P5GE_XBZ_PCS_REG_LEN (0x844) Should the PCS registers actually be in the PCS driver, not the PHY driver? Hard to say until we know what these registers actually are. > #define MT7987_2P5GE_CHIP_SCU_BASE (0x0f0cf800) > #define MT7987_2P5GE_CHIP_SCU_LEN (0x12c) > > static int mt7988_2p5ge_phy_load_fw(struct phy_device *phydev) > { > struct mtk_i2p5ge_phy_priv *priv = phydev->priv; > void __iomem *mcu_csr_base, *pmb_addr; > struct device *dev = &phydev->mdio.dev; > const struct firmware *fw; > int ret, i; > u32 reg; > > if (priv->fw_loaded) > return 0; > > pmb_addr = ioremap(MTK_2P5GPHY_PMB_FW_BASE, > MT7988_2P5GE_PMB_FW_LEN); > if (!pmb_addr) > return -ENOMEM; > mcu_csr_base = ioremap(MTK_2P5GPHY_MCU_CSR_BASE, > MTK_2P5GPHY_MCU_CSR_LEN); > if (!mcu_csr_base) { > ret = -ENOMEM; > goto free_pmb; > } > ... > free: > iounmap(mcu_csr_base); > free_pmb: > iounmap(pmb_addr); > ... > } This looks O.K. It is basically what we did before device tree was used. Andrew