Message ID | 20240216184237.259954-3-florian.fainelli@broadcom.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp66708dyc; Fri, 16 Feb 2024 16:12:14 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW9vQCsksp6TALmZQa877psENvP7J6K7ZqS79UKLw9/hg0jawXeXDwuz8BfvgHPpHE8VL88Hf1j1PJvlYFT3zM+Mpubug== X-Google-Smtp-Source: AGHT+IHuBIEuDrdlBmkfsoYClcFTeCNxkKhVG3/UYWFdzzmsLX4AArZxTuO6xWcdMgYq6DI0Uj9X X-Received: by 2002:a17:906:d9c8:b0:a3d:4ac5:2012 with SMTP id qk8-20020a170906d9c800b00a3d4ac52012mr4454391ejb.25.1708128734092; Fri, 16 Feb 2024 16:12:14 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708128734; cv=pass; d=google.com; s=arc-20160816; b=isw/SRpb5F3K+9rdJL7WQ4EdaVtJmBLES/574IBE59RMMBB+wojkQGUhsWWgNvuvWR 7zotIQxxYbyk2BPy1IMoplMy/MXLdSl7eZWHgjfP1pnfx9jMuPtoKYSF/aw1Az//RNon 6+fxwEZrAnZhQBthPDVuVLZZlJsGd/Z0kryYa7J8xSCKn/aNsV3PdoQAHRDUWbli0D01 WJ2/fnPfqCl6foq7ZCs9IQ1EugBB/pN1vgURNh9TjXR7P3WYWj514NAReWd0ijYuQ2qL e989gF2D8KZkkR4suowjXGJlH8ZLN2bk2DYjV85OWWw9euPHIobgKAQGfPfE3CTCwX8C DQZA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature:dkim-filter; bh=9Kyt2HvLplNXvCF1UNtmucaaOjaedLaQBGW0qxy8u0Q=; fh=qrdLH5V6S6EHhdSAR+OVGwuqNaPW77Tf5cttX4TmYBA=; b=WDBAj6Ly20YSu5WQTRedvfTyEVTrxOWULVZWTkonJSoqgemQTOKOr4CA+pPwgC59WN MAiW8MBw3pqskL0CBMDiC6sxSMg4u+F8N6JIHysjwkeYerM13EydY+rGl261Co445dMR IsuPfIMdO1ACFCocts+9j3pWHYNDcg0pGkBUApscqiYd1qLfJsdNRsM4plhob0lT6PL2 UKa2KfbHtqPj0k7rH9lPV9kXC2zPh6Tpj2lKn6B2RQpnOWQTbyPw5dnw1Am5Q9zQUp2Q CP4Kq4iyDNa+JrVjQGu/1R5i1NuCNNOEQ5z6mOmA71nTmoV9H7EkMl7XT83Ds9SMHlBu B/iQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@broadcom.com header.s=dkimrelay header.b=JWlLMDNU; arc=pass (i=1 dkim=pass dkdomain=broadcom.com dmarc=pass fromdomain=broadcom.com); spf=pass (google.com: domain of linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id fx26-20020a170906b75a00b00a3e1226ddd8si251233ejb.996.2024.02.16.16.12.13 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 16:12:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=dkimrelay header.b=JWlLMDNU; arc=pass (i=1 dkim=pass dkdomain=broadcom.com dmarc=pass fromdomain=broadcom.com); spf=pass (google.com: domain of linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69192-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 039EC1F23722 for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 18:46:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 917EC14A089; Fri, 16 Feb 2024 18:42:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="JWlLMDNU" Received: from relay.smtp-ext.broadcom.com (unknown [192.19.166.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 744C31350FB; Fri, 16 Feb 2024 18:42:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.19.166.231 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708108972; cv=none; b=GNdhAIHrb759bNvN09MZdOwfixYdAjJq2nnk34InBJrQeoAsbo5zVqytFJnKREkAxeEEHJt07Kv1lv77buLCxIXDSJnFX9NdNCCVeBj6Iv6TS4yvWgDBXcFiqJYCe5xYtl+4gZpR3yqe/V/fcbH8chaxXgj+r/z5Qlmq/xOp+v4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708108972; c=relaxed/simple; bh=i9k3K96piVEikMIz1+hmpkE1mIU1mvLihqfUZnhngpg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Bvk7fqj2erGx6IL/mTH3jrZ8osXEgW/S0Vc7e0SjTpbSE/pT9XNTfqn3bk50pmsYnuqm+yNSchGDKVWnndOF5V0ruO2onRHbuQbQE2KsIdXKDt2SDlqSK67c7POmxa8lK9c9AnL1Q8di29jbqjokPSam5FFqar+hIvkVDubM72o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=JWlLMDNU; arc=none smtp.client-ip=192.19.166.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Received: from mail-lvn-it-01.lvn.broadcom.net (mail-lvn-it-01.lvn.broadcom.net [10.36.132.253]) by relay.smtp-ext.broadcom.com (Postfix) with ESMTP id 41628C001645; Fri, 16 Feb 2024 10:42:44 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com 41628C001645 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1708108964; bh=i9k3K96piVEikMIz1+hmpkE1mIU1mvLihqfUZnhngpg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JWlLMDNUIQVlrb/EVKF/dk8fEIJvopreIsxpUCoO7nxUIkrJ6gOGCuE8aKTcHRE9a 6qD1F2aN7+hE+zbbxuacaz45WZG4SPfUHVrK9wSeLZoOct7ymlGge+lFetseCtfQQc LNY38g7VwzgZv38I7IgGL5TvBdaIXwGDvVaGUX+Y= Received: from fainelli-desktop.igp.broadcom.net (fainelli-desktop.dhcp.broadcom.net [10.67.48.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail-lvn-it-01.lvn.broadcom.net (Postfix) with ESMTPSA id AB8CA18041CAC7; Fri, 16 Feb 2024 10:42:42 -0800 (PST) From: Florian Fainelli <florian.fainelli@broadcom.com> To: netdev@vger.kernel.org Cc: Florian Fainelli <florian.fainelli@broadcom.com>, Doug Berger <opendmb@gmail.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org (open list), Justin Chen <justin.chen@broadcom.com> Subject: [PATCH net-next 2/3] net: bcmgenet: Pass "main" clock down to the MDIO driver Date: Fri, 16 Feb 2024 10:42:36 -0800 Message-Id: <20240216184237.259954-3-florian.fainelli@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240216184237.259954-1-florian.fainelli@broadcom.com> References: <20240216184237.259954-1-florian.fainelli@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791097226603197075 X-GMAIL-MSGID: 1791102795431822424 |
Series |
Rework GENET MDIO controller clocking
|
|
Commit Message
Florian Fainelli
Feb. 16, 2024, 6:42 p.m. UTC
GENET has historically had to create a MDIO platform device for its
controller and pass some auxiliary data to it, like a MDIO completion
callback. Now we also pass the "main" clock to allow for the MDIO bus
controller to manage that clock adequately around I/O accesses.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
On 2/16/24 14:41, Jacob Keller wrote: > > > On 2/16/2024 10:42 AM, Florian Fainelli wrote: >> GENET has historically had to create a MDIO platform device for its >> controller and pass some auxiliary data to it, like a MDIO completion >> callback. Now we also pass the "main" clock to allow for the MDIO bus >> controller to manage that clock adequately around I/O accesses. >> >> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> >> --- >> drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c >> index cbbe004621bc..7a21950da77c 100644 >> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c >> +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c >> @@ -476,6 +476,10 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv) >> ppd.wait_func = bcmgenet_mii_wait; >> ppd.wait_func_data = priv; >> ppd.bus_name = "bcmgenet MII bus"; >> + /* Pass a reference to our "main" clock which is used for MDIO >> + * transfers >> + */ >> + ppd.clk = priv->clk; >> >> /* Unimac MDIO bus controller starts at UniMAC offset + MDIO_CMD >> * and is 2 * 32-bits word long, 8 bytes total. > > Is this missing a modification of the header file to add the clk field > to struct unimac_mdio_pdata? I don't see that field in the > include/linux/platform_data/mdio-bcm-unimac.h header currently... > > Oh. you included that in the first patch of the series. I see. I suppose I could have included it in patch #1, and have introduced in patch #2 the hunk that dealt with fetching pdata->clk, but since I was re-organizing the mdio-bcm-unimac.c driver's probe function, it felt more natural to arrange it that way. > > It feels like the series would be more natural of this was 1/3 instead > of 2/3, since the current 1/3 patch depends on this clk value being set, no? I sort of debated that with myself, and ended up going with: put the plumbing first, wire it later, rather than the opposite. If someone was to run a bisection there would not be any difference in behavior until patch #2 regardless of their ordering. > > The result of the series makes sense tho: > > Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Thanks Jacob!
On Fri, Feb 16, 2024 at 10:42:36AM -0800, Florian Fainelli wrote: > GENET has historically had to create a MDIO platform device for its > controller and pass some auxiliary data to it, like a MDIO completion > callback. Now we also pass the "main" clock to allow for the MDIO bus > controller to manage that clock adequately around I/O accesses. I guess this code comes from before the times of DT? I would normally expect to see a clock added to the DT node for the MDIO bus. But if there is no node, because it is not in DT.... Andrew
Hi Andrew, On 2/17/2024 7:21 AM, Andrew Lunn wrote: > On Fri, Feb 16, 2024 at 10:42:36AM -0800, Florian Fainelli wrote: >> GENET has historically had to create a MDIO platform device for its >> controller and pass some auxiliary data to it, like a MDIO completion >> callback. Now we also pass the "main" clock to allow for the MDIO bus >> controller to manage that clock adequately around I/O accesses. > > I guess this code comes from before the times of DT? I would normally > expect to see a clock added to the DT node for the MDIO bus. But if > there is no node, because it is not in DT.... The driver started being DT-only from the get go, however it was also my group's first attempt at upstreaming a driver and we did not get everything right in terms of the DT binding. In particular there was no "mdio" sub-node initially, but we still wanted to be able to split up the MDIO controller part since we knew it was going to be re-used in other designs (bcm_sf2 and later asp2). The platform device was the best we could come up with at the time. All of our DTBs deployed out there do not have a "clocks" property within the "mdio" sub-mode of the GENET Ethernet node, so that is why we are doing this. Thanks!
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c index cbbe004621bc..7a21950da77c 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c @@ -476,6 +476,10 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv) ppd.wait_func = bcmgenet_mii_wait; ppd.wait_func_data = priv; ppd.bus_name = "bcmgenet MII bus"; + /* Pass a reference to our "main" clock which is used for MDIO + * transfers + */ + ppd.clk = priv->clk; /* Unimac MDIO bus controller starts at UniMAC offset + MDIO_CMD * and is 2 * 32-bits word long, 8 bytes total.