From: Marek Vasut <marex@denx.de>
To: Christophe ROULLIER <christophe.roullier@foss.st.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Richard Cochran <richardcochran@gmail.com>,
Jose Abreu <joabreu@synopsys.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 03/11] net: stmmac: dwmac-stm32: rework glue to simplify management
Date: Mon, 13 May 2024 16:23:30 +0200 [thread overview]
Message-ID: <2b1ed649-ab05-4cfe-86be-96e1a96ec76f@denx.de> (raw)
In-Reply-To: <4da0ce80-2120-4d67-aaaa-7dbf13b1da73@foss.st.com>
On 5/13/24 2:48 PM, Christophe ROULLIER wrote:
> Hi
>
> On 4/26/24 16:53, Marek Vasut wrote:
>> On 4/26/24 2:56 PM, Christophe Roullier wrote:
>>> Change glue to be more generic and manage easily next stm32 products.
>>> The goal of this commit is to have one stm32mp1_set_mode function which
>>> can manage different STM32 SOC. SOC can have different SYSCFG register
>>> bitfields. so in pmcsetr we defined the bitfields corresponding to
>>> the SOC.
>>>
>>> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
>>> ---
>>> .../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 76 +++++++++++++------
>>> 1 file changed, 51 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> index c92dfc4ecf57..68a02de25ac7 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> @@ -23,10 +23,6 @@
>>> #define SYSCFG_MCU_ETH_MASK BIT(23)
>>> #define SYSCFG_MP1_ETH_MASK GENMASK(23, 16)
>>> -#define SYSCFG_PMCCLRR_OFFSET 0x40
>>> -
>>> -#define SYSCFG_PMCR_ETH_CLK_SEL BIT(16)
>>> -#define SYSCFG_PMCR_ETH_REF_CLK_SEL BIT(17)
>>> /* CLOCK feed to PHY*/
>>> #define ETH_CK_F_25M 25000000
>>> @@ -46,9 +42,6 @@
>>> * RMII | 1 | 0 | 0 | n/a |
>>> *------------------------------------------
>>> */
>>> -#define SYSCFG_PMCR_ETH_SEL_MII BIT(20)
>>> -#define SYSCFG_PMCR_ETH_SEL_RGMII BIT(21)
>>> -#define SYSCFG_PMCR_ETH_SEL_RMII BIT(23)
>>> #define SYSCFG_PMCR_ETH_SEL_GMII 0
>>> #define SYSCFG_MCU_ETH_SEL_MII 0
>>> #define SYSCFG_MCU_ETH_SEL_RMII 1
>>> @@ -90,19 +83,33 @@ struct stm32_dwmac {
>>> int eth_ref_clk_sel_reg;
>>> int irq_pwr_wakeup;
>>> u32 mode_reg; /* MAC glue-logic mode register */
>>> + u32 mode_mask;
>>> struct regmap *regmap;
>>> u32 speed;
>>> const struct stm32_ops *ops;
>>> struct device *dev;
>>> };
>>> +struct stm32_syscfg_pmcsetr {
>>> + u32 eth1_clk_sel;
>>> + u32 eth1_ref_clk_sel;
>>> + u32 eth1_selmii;
>>> + u32 eth1_sel_rgmii;
>>> + u32 eth1_sel_rmii;
>>> + u32 eth2_clk_sel;
>>> + u32 eth2_ref_clk_sel;
>>> + u32 eth2_sel_rgmii;
>>> + u32 eth2_sel_rmii;
>>> +};
>>
>> [...]
>>
>>> @@ -487,8 +502,19 @@ static struct stm32_ops stm32mp1_dwmac_data = {
>>> .suspend = stm32mp1_suspend,
>>> .resume = stm32mp1_resume,
>>> .parse_data = stm32mp1_parse_data,
>>> - .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK,
>>> - .clk_rx_enable_in_suspend = true
>>> + .clk_rx_enable_in_suspend = true,
>>> + .syscfg_clr_off = 0x44,
>>> + .pmcsetr = {
>>> + .eth1_clk_sel = BIT(16),
>>> + .eth1_ref_clk_sel = BIT(17),
>>> + .eth1_selmii = BIT(20),
>>> + .eth1_sel_rgmii = BIT(21),
>>> + .eth1_sel_rmii = BIT(23),
>>> + .eth2_clk_sel = 0,
>>> + .eth2_ref_clk_sel = 0,
>>> + .eth2_sel_rgmii = 0,
>>> + .eth2_sel_rmii = 0
>>> + }
>>> };
>>
>> Is this structure really necessary ?
>>
> I prefer to keep this implementation for the moment, as it is working
> fine. Maybe at a later stage, I will send some optimizations.
BIT() and left shift by 8 works all the same, without all this
complexity and new structures, since all you really have on MP13 are two
identical bitfields (one at offset 16, the other at offset 24) with the
same bits in them, so why not make this simple ?
next prev parent reply other threads:[~2024-05-13 15:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 12:56 [PATCH v2 00/11] Series to deliver Ethernets for STM32MP13 Christophe Roullier
2024-04-26 12:56 ` [PATCH v2 01/11] dt-bindings: net: add STM32MP13 compatible in documentation for stm32 Christophe Roullier
2024-04-26 14:46 ` Marek Vasut
2024-04-26 19:16 ` Rob Herring
2024-04-26 12:56 ` [PATCH v2 02/11] dt-bindings: net: add phy-supply property " Christophe Roullier
2024-04-26 14:47 ` Marek Vasut
2024-05-13 11:45 ` Christophe ROULLIER
2024-05-13 14:16 ` Marek Vasut
2024-04-26 15:30 ` Rob Herring
2024-05-13 14:06 ` Christophe ROULLIER
2024-05-13 14:20 ` Marek Vasut
2024-04-26 12:56 ` [PATCH v2 03/11] net: stmmac: dwmac-stm32: rework glue to simplify management Christophe Roullier
2024-04-26 14:53 ` Marek Vasut
2024-05-13 12:48 ` Christophe ROULLIER
2024-05-13 14:23 ` Marek Vasut [this message]
2024-04-26 12:57 ` [PATCH v2 04/11] net: stmmac: dwmac-stm32: add management of stm32mp13 Christophe Roullier
2024-04-26 12:57 ` [PATCH v2 05/11] net: stmmac: dwmac-stm32: update config management for phy wo cristal Christophe Roullier
2024-04-26 15:37 ` Marek Vasut
2024-05-13 15:11 ` Christophe ROULLIER
2024-05-13 22:33 ` Marek Vasut
2024-04-26 12:57 ` [PATCH v2 06/11] net: stmmac: dwmac-stm32: clean the way to manage wol irqwake Christophe Roullier
2024-04-26 15:40 ` Marek Vasut
2024-05-13 15:14 ` Christophe ROULLIER
2024-04-26 12:57 ` [PATCH v2 07/11] net: stmmac: dwmac-stm32: support the phy-supply regulator binding Christophe Roullier
2024-04-26 15:48 ` Marek Vasut
2024-04-26 12:57 ` [PATCH v2 08/11] ARM: dts: stm32: add ethernet1 and ethernet2 support on stm32mp13 Christophe Roullier
2024-04-26 12:57 ` [PATCH v2 09/11] ARM: dts: stm32: add ethernet1/2 RMII pins for STM32MP13F-DK board Christophe Roullier
2024-04-26 12:57 ` [PATCH v2 10/11] ARM: dts: stm32: add ethernet1 and ethernet2 for STM32MP135F-DK board Christophe Roullier
2024-04-26 15:44 ` Marek Vasut
2024-05-13 16:01 ` Alexandre TORGUE
2024-05-16 0:23 ` Marek Vasut
2024-05-16 7:58 ` Alexandre TORGUE
2024-05-16 12:22 ` Andrew Lunn
2024-05-17 7:30 ` Alexandre TORGUE
2024-04-26 12:57 ` [PATCH v2 11/11] ARM: multi_v7_defconfig: Add MCP23S08 pinctrl support Christophe Roullier
2024-04-26 14:22 ` [PATCH v2 00/11] Series to deliver Ethernets for STM32MP13 Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b1ed649-ab05-4cfe-86be-96e1a96ec76f@denx.de \
--to=marex@denx.de \
--cc=alexandre.torgue@foss.st.com \
--cc=broonie@kernel.org \
--cc=christophe.roullier@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).