From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AF3213D66; Fri, 31 Jan 2025 15:03:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738335799; cv=none; b=m4g2TT0tTpuylXPF9BR8sIbSvM7O3A0drSgHNfReq6DJmkTRQ3gt/vLKUicm8JauEHLz+m6W0Bc8fOydaMfP1nMkdU7cAOulbOoX9Sw9LDoGEBCEh6UNZxYXMtHqTjdtfp3O3QS3PB6pHgJWOvmgrSH4NnQsjnxKXFG6Tkc9h0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738335799; c=relaxed/simple; bh=y8udIcxdrbNjwq612CEizD0X1c7DqRt6OGB3wweQYr8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UNIyFJdYkQ1xNh6WWrjmpIiGf8RUna6bulLLc1m9usTtQC2rQ51kRiu5CAD1WBB0SUR1K+LzfvrXxT4MFZWBO2i8stOO2AF85qQ6wGm4vREnxvn90bzRCDq54CUsgwrQPUZOGWqnVcvu62ts+48dF6a/cRm/K1Wa05oaTNc1buI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0E983497; Fri, 31 Jan 2025 07:03:42 -0800 (PST) Received: from [10.1.32.52] (e122027.cambridge.arm.com [10.1.32.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 996973F694; Fri, 31 Jan 2025 07:03:13 -0800 (PST) Message-ID: Date: Fri, 31 Jan 2025 15:03:11 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v4 3/3] net: stmmac: Specify hardware capability value when FIFO size isn't specified To: Andrew Lunn Cc: Kunihiko Hayashi , Alexandre Torgue , Jose Abreu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Russell King , Yanteng Si , Furong Xu <0x1207@gmail.com>, Joao Pinto , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20250127013820.2941044-1-hayashi.kunihiko@socionext.com> <20250127013820.2941044-4-hayashi.kunihiko@socionext.com> <07af1102-0fa7-45ad-bcbc-aef0295ceb63@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31/01/2025 14:47, Andrew Lunn wrote: >>> I'm guessing, but in your setup, i assume the value is never written >>> to a register, hence 0 is O.K. e.g. dwmac1000_dma_operation_mode_rx(), >>> the fifosz value is used to determine if flow control can be used, but >>> is otherwise ignored. >> >> I haven't traced the code, but that fits my assumptions too. > > I could probably figure it out using code review, but do you know > which set of DMA operations your hardware uses? A quick look at > dwmac-rk.c i see: > > /* If the stmmac is not already selected as gmac4, > * then make sure we fallback to gmac. > */ > if (!plat_dat->has_gmac4) > plat_dat->has_gmac = true; has_gmac4 is false on this board, so has_gmac will be set to true here. The DT compatible is rockchip,rk3288-gmac Steve > Which suggests there are two variants of the RockChip MAC. > > Andrew