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: Thu, 11 Aug 2022 11:23:58 +0200 [thread overview]
Message-ID: <9aa60160-8d8e-477f-991a-b2f4cc72ddf6@prolan.hu> (raw)
In-Reply-To: <YvRH06S/7E6J8RY0@lunn.ch>
On 2022. 08. 11. 2:05, Andrew Lunn wrote:
>>>
>>>> /* 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.
>
> We should decide what fep->pps_enable actually means. It should be
> enabled, or it is actually enabled? Then it becomes clear if the reset
> function should clear it to reflect the hardware, or if the
> fec_ptp_enable_pps() should not be looking at it, and needs to read
> the status from the hardware.
>
`fep->pps_enable` is the state of the PPS the driver *believes* to be
the case. After a reset, this belief may or may not be true anymore: if
the driver believed formerly that the PPS is down, then after a reset,
its belief will still be correct, thus nothing needs to be done about
the situation. If, however, the driver thought that PPS was up, after
controller reset, it no longer holds, so we need to update our
world-view (`fep->pps_enable = 0;`), and then correct for the fact that
PPS just unexpectedly stopped.
>>> 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).
>
> Never trust userspace. Ever.
Amen. Said issue is already fixed in the next version of the patch.
>
> Andrew
Bence
next prev parent reply other threads:[~2022-08-11 9:24 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
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 [this message]
2022-08-11 13:30 ` Andrew Lunn
2022-08-11 14:45 ` Csókás Bence
-- strict thread matches above, loose matches on Subject: below --
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=9aa60160-8d8e-477f-991a-b2f4cc72ddf6@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 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.