All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yanteng Si <si.yanteng@linux.dev>
To: "Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Richard Cochran" <richardcochran@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: stmmac: add explicit check and error on invalid PTP clock rate
Date: Tue, 27 May 2025 17:52:26 +0800	[thread overview]
Message-ID: <6147503e-1e73-42dc-a2b9-1b0cf26ca147@linux.dev> (raw)
In-Reply-To: <DA666WVCP2OB.300LVHEGH5V4Y@bootlin.com>


在 5/26/25 10:42 PM, Alexis Lothoré 写道:
> On Mon May 26, 2025 at 4:22 AM CEST, Yanteng Si wrote:
>> 在 5/23/25 7:46 PM, Alexis Lothoré 写道:
>>> While some platforms implementing dwmac open-code the clk_ptp_rate
>>> value, some others dynamically retrieve the value at runtime. If the
>>> retrieved value happens to be 0 for any reason, it will eventually
>>> propagate up to PTP initialization when bringing up the interface,
>>> leading to a divide by 0:
> [...]
>
>>   From your description, I cannot determine the scope
>> of "some platforms". My point is: if there are only
>> a few platforms, can we find a way to handle this in
>> the directory of the corresponding platform?
>  From what I can see, it can affect any platform using the stmmac driver as
> the platform driver (except maybe dwmac-qcom-ethqos.c, which enforces an
> open-coded clk_ptp_rate after the stmmac_probe_config_dt call that sets
> the clk_ptp_rate), if the platform declares a dedicated clk_ptp_ref clock.
> So I would rather say that it can affect most of the platforms.
>
> In my case, I have observed the issue with the dwmac-stm32.c driver, on an
> STM32MP157a-dk1 platform.
Okay!
>
>> And there need a Fixes tag.
> Ok, I'll add a relevant Fixes tag.

On this premise,


Reviewed-by: Yanteng Si <si.yanteng@linux.dev>


Thanks,

Yanteng

>
> Alexis
>
>>> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
>>> ---
>>>    drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> index 918d7f2e8ba992208d7d6521a1e9dba01086058f..f68e3ece919cc88d0bf199a394bc7e44b5dee095 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -835,6 +835,11 @@ int stmmac_init_tstamp_counter(struct stmmac_priv *priv, u32 systime_flags)
>>>    	if (!(priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp))
>>>    		return -EOPNOTSUPP;
>>>    
>>> +	if (!priv->plat->clk_ptp_rate) {
>>> +		netdev_err(priv->dev, "Invalid PTP clock rate");
>>> +		return -EINVAL;
>>> +	}
>>> +
>>>    	stmmac_config_hw_tstamping(priv, priv->ptpaddr, systime_flags);
>>>    	priv->systime_flags = systime_flags;
>>>    
>>>
>>> ---
>>> base-commit: e0e2f78243385e7188a57fcfceb6a19f723f1dff
>>> change-id: 20250522-stmmac_tstamp_div-f55112f06029
>>>
>>> Best regards,
>
>
>


      reply	other threads:[~2025-05-27  9:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-23 11:46 [PATCH] net: stmmac: add explicit check and error on invalid PTP clock rate Alexis Lothoré
2025-05-26  2:22 ` Yanteng Si
2025-05-26 14:42   ` Alexis Lothoré
2025-05-27  9:52     ` Yanteng Si [this message]

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=6147503e-1e73-42dc-a2b9-1b0cf26ca147@linux.dev \
    --to=si.yanteng@linux.dev \
    --cc=alexandre.torgue@foss.st.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.