If the internal flash contains missing or corrupted configuration,
basic communication over the bus still functions, but the device
is not capable of normal operation (for example, using mailboxes).

This condition is indicated in the info register by the ready bit.
If this bit is cleared, the probe procedure times out while fetching
the device state.

Handle this case by checking the ready bit value in zl3073x_dev_start()
and skipping DPLL device and pin registration if it is cleared.
Do not report this condition as an error, allowing the devlink device
to be registered and enabling the user to flash the correct configuration.

Prior this patch:
[   31.112299] zl3073x-i2c 1-0070: Failed to fetch input state: -ETIMEDOUT
[   31.116332] zl3073x-i2c 1-0070: error -ETIMEDOUT: Failed to start device
[   31.136881] zl3073x-i2c 1-0070: probe with driver zl3073x-i2c failed with error -110

After this patch:
[   41.011438] zl3073x-i2c 1-0070: FW not fully ready - missing or corrupted config

Fixes: 75a71ecc24125 ("dpll: zl3073x: Register DPLL devices and pins")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
 drivers/dpll/zl3073x/core.c | 21 +++++++++++++++++++++
 drivers/dpll/zl3073x/regs.h |  3 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 092e7027948a..e42e527813cf 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -1038,8 +1038,29 @@ zl3073x_dev_phase_meas_setup(struct zl3073x_dev *zldev)
 int zl3073x_dev_start(struct zl3073x_dev *zldev, bool full)
 {
 	struct zl3073x_dpll *zldpll;
+	u8 info;
 	int rc;
 
+	rc = zl3073x_read_u8(zldev, ZL_REG_INFO, &info);
+	if (rc) {
+		dev_err(zldev->dev, "Failed to read device status info\n");
+		return rc;
+	}
+
+	if (!FIELD_GET(ZL_INFO_READY, info)) {
+		/* The ready bit indicates that the firmware was successfully
+		 * configured and is ready for normal operation. If it is
+		 * cleared then the configuration stored in flash is wrong
+		 * or missing. In this situation the driver will expose
+		 * only devlink interface to give an opportunity to flash
+		 * the correct config.
+		 */
+		dev_info(zldev->dev,
+			 "FW not fully ready - missing or corrupted config\n");
+
+		return 0;
+	}
+
 	if (full) {
 		/* Fetch device state */
 		rc = zl3073x_dev_state_fetch(zldev);
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
index 19a25325bd9c..d837bee72b17 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -67,6 +67,9 @@
  * Register Page 0, General
  **************************/
 
+#define ZL_REG_INFO				ZL_REG(0, 0x00, 1)
+#define ZL_INFO_READY				BIT(7)
+
 #define ZL_REG_ID				ZL_REG(0, 0x01, 2)
 #define ZL_REG_REVISION				ZL_REG(0, 0x03, 2)
 #define ZL_REG_FW_VER				ZL_REG(0, 0x05, 2)
-- 
2.49.1

On Wed, Oct 08, 2025 at 04:14:45PM +0200, Ivan Vecera wrote:
> If the internal flash contains missing or corrupted configuration,
> basic communication over the bus still functions, but the device
> is not capable of normal operation (for example, using mailboxes).
> 
> This condition is indicated in the info register by the ready bit.
> If this bit is cleared, the probe procedure times out while fetching
> the device state.
> 
> Handle this case by checking the ready bit value in zl3073x_dev_start()
> and skipping DPLL device and pin registration if it is cleared.
> Do not report this condition as an error, allowing the devlink device
> to be registered and enabling the user to flash the correct configuration.
> 
> Prior this patch:
> [   31.112299] zl3073x-i2c 1-0070: Failed to fetch input state: -ETIMEDOUT
> [   31.116332] zl3073x-i2c 1-0070: error -ETIMEDOUT: Failed to start device
> [   31.136881] zl3073x-i2c 1-0070: probe with driver zl3073x-i2c failed with error -110
> 
> After this patch:
> [   41.011438] zl3073x-i2c 1-0070: FW not fully ready - missing or corrupted config
> 
> Fixes: 75a71ecc24125 ("dpll: zl3073x: Register DPLL devices and pins")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>

I am unsure how much precedence there is for probing a device
with very limited functionality like this. But, the approach
does make sense to me as it provides a path for user intervention
to address the detected problem which at any rate renders the probed
driver inoperable.

Reviewed-by: Simon Horman <horms@kernel.org>

...

On Mon, 13 Oct 2025 10:15:05 +0100 Simon Horman wrote:
> I am unsure how much precedence there is for probing a device
> with very limited functionality like this.

Off the top of my head some Intel and Meta drivers do it already, IIRC.

On Mon, Oct 13, 2025 at 05:28:02PM -0700, Jakub Kicinski wrote:
> On Mon, 13 Oct 2025 10:15:05 +0100 Simon Horman wrote:
> > I am unsure how much precedence there is for probing a device
> > with very limited functionality like this.
> 
> Off the top of my head some Intel and Meta drivers do it already, IIRC.

Thanks, I think that is sufficient to allay my minor doubts here.