From: "Csókás Bence" <csokas.bence@prolan.hu>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <netdev@vger.kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
Fugang Duan <fugang.duan@nxp.com>
Subject: Re: [PATCH] fec: Restart PPS after link state change
Date: Wed, 10 Aug 2022 13:36:54 +0200 [thread overview]
Message-ID: <299d74d5-2d56-23f6-affc-78bb3ae3e03c@prolan.hu> (raw)
In-Reply-To: <YvKZNcVfYdLw7bkm@lunn.ch>
On 2022. 08. 09. 19:28, Andrew Lunn wrote:
> On Tue, Aug 09, 2022 at 02:41:19PM +0200, Csókás Bence wrote:
>> On link state change, the controller gets reset,
>> causing PPS to drop out. So we restart it if needed.
>>
>> Signed-off-by: Csókás Bence <csokas.bence@prolan.hu>
>> ---
>> drivers/net/ethernet/freescale/fec_main.c | 27 ++++++++++++++++++++++-
>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
>> index ca5d49361fdf..c264b1dd5286 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -954,6 +954,7 @@ fec_restart(struct net_device *ndev)
>> u32 temp_mac[2];
>> u32 rcntl = OPT_FRAME_SIZE | 0x04;
>> u32 ecntl = 0x2; /* ETHEREN */
>> + struct ptp_clock_request ptp_rq = { .type = PTP_CLK_REQ_PPS };
>
> Is it safe to hard code this? What if the user configured
> PTP_CLK_REQ_EXTTS or PTP_CLK_REQ_PEROUT?
The fec driver doesn't support anything other than PTP_CLK_REQ_PPS. And
if it will at some point, this will need to be amended anyways.
>
>> /* Whack a reset. We should wait for this.
>> * For i.MX6SX SOC, enet use AXI bus, we use disable MAC
>> @@ -1119,6 +1120,13 @@ fec_restart(struct net_device *ndev)
>> if (fep->bufdesc_ex)
>> fec_ptp_start_cyclecounter(ndev);
>>
>> + /* Restart PPS if needed */
>> + if (fep->pps_enable) {
>> + /* Clear flag so fec_ptp_enable_pps() doesn't return immediately */
>> + fep->pps_enable = 0;
>
> If reset causes PPS to stop, maybe it would be better to do this
> unconditionally?
But if it wasn't enabled before the reset in the first place, we
wouldn't want to unexpectedly start it.
>
> fep->pps_enable = 0;
> fep->ptp_caps.enable(&fep->ptp_caps, &ptp_rq, 1);
>
>> + if (fep->bufdesc_ex)
>> + ecntl |= (1 << 4);
>
> Please replace (1 << 4) with a #define to make it clear what this is doing.
I took it from the original source, line 1138 as of commit #504148f. It
is the EN1588 bit by the way. I shall replace it with a #define in both
places then. Though the code is riddled with other magic numbers without
explanation, and I probably won't be bothered to fix them all.
>
>> +
>> /* We have to keep ENET enabled to have MII interrupt stay working */
>> if (fep->quirks & FEC_QUIRK_ENET_MAC &&
>> !(fep->wol_flag & FEC_WOL_FLAG_SLEEP_ON)) {
>> - writel(2, fep->hwp + FEC_ECNTRL);
>> + ecntl |= 0x2;
>> writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
>> }
>> +
>> + writel(ecntl, fep->hwp + FEC_ECNTRL);
>> +
>> + if (fep->bufdesc_ex)
>> + fec_ptp_start_cyclecounter(ndev);
>> +
>> + /* Restart PPS if needed */
>> + if (fep->pps_enable) {
>> + /* Clear flag so fec_ptp_enable_pps() doesn't return immediately */
>> + fep->pps_enable = 0;
>> + fep->ptp_caps.enable(&fep->ptp_caps, &ptp_rq, 1);
>> + }
>
> So you re-start PPS in stop()? Should it keep outputting when the
> interface is down?
Yes. We use PPS to synchronize devices on a common backplane. We use PTP
to sync this PPS to a master clock. But if PTP sync drops out, we
wouldn't want the backplane-level synchronization to fail. The PPS needs
to stay on as long as userspace *explicitly* disables it, regardless of
what happens to the link.
>
> Also, if it is always outputting, don't you need to stop it in
> fec_drv_remove(). You probably don't want to still going after the
> driver is unloaded.
Good point, that is one exception we could make to the above statement
(though even in this case, userspace *really* should disable PPS before
unloading the module).
>
> Andrew
Thanks for the insights,
Bence
next prev parent reply other threads:[~2022-08-10 11:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 12:41 [PATCH] fec: Restart PPS after link state change Csókás Bence
2022-08-09 17:28 ` Andrew Lunn
2022-08-10 11:36 ` Csókás Bence [this message]
2022-08-11 0:05 ` Andrew Lunn
2022-08-11 1:37 ` Richard Cochran
2022-08-11 2:05 ` Andrew Lunn
2022-08-11 8:07 ` Csókás Bence
2022-08-11 16:38 ` Richard Cochran
2022-08-11 9:23 ` Csókás Bence
2022-08-11 13:30 ` Andrew Lunn
2022-08-11 14:45 ` Csókás Bence
2022-08-10 14:00 Csókás Bence
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=299d74d5-2d56-23f6-affc-78bb3ae3e03c@prolan.hu \
--to=csokas.bence@prolan.hu \
--cc=andrew@lunn.ch \
--cc=fugang.duan@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.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 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).