From: Sagi Maimon <maimon.sagi@gmail.com>
To: Richard Cochran <richardcochran@gmail.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Simon Horman <horms@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <skhan@linuxfoundation.org>,
netdev@vger.kernel.org
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Sagi Maimon <maimon.sagi@gmail.com>
Subject: [PATCH net-next 9/9] ptp: ocp: confirm the CPLD really left configuration mode after REFRESH
Date: Tue, 22 Sep 2026 17:28:29 +0300 [thread overview]
Message-ID: <20260922142829.57740-10-maimon.sagi@gmail.com> (raw)
In-Reply-To: <20260922142829.57740-1-maimon.sagi@gmail.com>
The post-REFRESH check required DONE set, BUSY clear and no error code.
Those three conditions are already satisfied by the state SET_DONE leaves
behind, so they cannot distinguish a REFRESH that rebooted the part from
one whose frame was ACKed but never latched - and the I2C ACK alone was
taken as proof, clearing cpld_in_config_mode.
A part left that way stays in configuration mode running the old image
while "devlink dev flash ... component fw.cpld" reports success, which is
the opposite of what the documentation promises.
Test CPLD_STATUS_ENAB as well: leaving configuration mode is the one
thing only a REFRESH does, so it is what separates the two cases. Put
cpld_in_config_mode back when ENAB is still set, so the exit path and the
recovery at the start of the next flash can act on it instead of
believing a mode change that never happened.
Fixes: a4b7c15aa78f ("ptp: ocp: add TAP CPLD flashing via devlink")
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
---
drivers/ptp/ptp_ocp.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
index 4f2bf54a23c2..9c2b7403bfd0 100644
--- a/drivers/ptp/ptp_ocp.c
+++ b/drivers/ptp/ptp_ocp.c
@@ -5135,6 +5135,9 @@ static int adva_x1_cpld_flash(struct ptp_ocp *bp, struct devlink *devlink,
/* REFRESH reboots the CPLD out of configuration mode, so the exit
* path must not send DIS_CFG afterwards even if a check below fails.
+ * The ENAB test below confirms it really left; until then assume it
+ * did, because sending DIS_CFG to a part that has rebooted is what
+ * this flag exists to avoid.
*/
bp->cpld_in_config_mode = false;
@@ -5156,12 +5159,21 @@ static int adva_x1_cpld_flash(struct ptp_ocp *bp, struct devlink *devlink,
/* Require DONE set, not busy and no error code, as machxo2-spi.c does
* after a refresh: without it a CRC or preamble error reads back as a
* successful update.
+ *
+ * ENAB has to be clear too. Those three conditions are already met
+ * by the state SET_DONE leaves behind, so on their own they cannot
+ * tell a REFRESH that rebooted the part from one whose frame was
+ * ACKed but never latched - which leaves the part in configuration
+ * mode still running the old image. Leaving configuration mode is
+ * the one thing only a REFRESH does.
*/
err = adva_x1_cpld_read_status(bp, &st);
if (err)
goto deselect;
+ if (st & CPLD_STATUS_ENAB)
+ bp->cpld_in_config_mode = true;
if (!(st & CPLD_STATUS_DONE) || (st & CPLD_STATUS_BUSY) ||
- (st & CPLD_STATUS_ERR)) {
+ (st & CPLD_STATUS_ERR) || (st & CPLD_STATUS_ENAB)) {
dev_err(&bp->pdev->dev,
"CPLD refresh left status 0x%08x\n", st);
NL_SET_ERR_MSG_MOD(extack, "CPLD did not come back configured");
--
2.47.0
next prev parent reply other threads:[~2026-09-22 14:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 14:28 [PATCH net-next 0/9] ptp: ocp: TAP CPLD follow-up fixes Sagi Maimon
2026-09-22 14:28 ` [PATCH net-next 1/9] ptp: ocp: move the CPLD identification read off the sync worker Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 2/9] ptp: ocp: do not cache EEPROM content after a failed TMC bus hand-back Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 3/9] ptp: ocp: hand the TMC bus back once on an acquire timeout Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 4/9] ptp: ocp: forget a CPLD i2c adapter number that no longer resolves Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 5/9] ptp: ocp: correct the CPLD bookkeeping comments and the flash progress Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 6/9] ptp: ocp: report fw.cpld with an empty value until the USERCODE is read Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 7/9] ptp: ocp: drop only the USERCODE when flashing, and drop it before erasing Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` [PATCH net-next 8/9] ptp: ocp: tolerate a latched FAILED when entering configuration mode Sagi Maimon
2026-09-24 14:29 ` netdev-bot+sashiko
2026-09-22 14:28 ` Sagi Maimon [this message]
2026-09-24 14:29 ` [PATCH net-next 9/9] ptp: ocp: confirm the CPLD really left configuration mode after REFRESH netdev-bot+sashiko
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=20260922142829.57740-10-maimon.sagi@gmail.com \
--to=maimon.sagi@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=arkadiusz.kubalewski@intel.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=richardcochran@gmail.com \
--cc=skhan@linuxfoundation.org \
--cc=vadim.fedorenko@linux.dev \
/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
all inboxes | Powered by JetHome®