linux-kernel - Re: [PATCH net-next v3 5/5] dpll: zl3073x: Implement devlink flash callback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250829165638.3b50ea2a@kernel.org>
Date: Fri, 29 Aug 2025 16:56:38 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jonathan Corbet
 <corbet@....net>, Prathosh Satish <Prathosh.Satish@...rochip.com>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, Michal Schmidt
 <mschmidt@...hat.com>, Petr Oros <poros@...hat.com>, Przemek Kitszel
 <przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH net-next v3 5/5] dpll: zl3073x: Implement devlink flash
 callback

On Fri, 29 Aug 2025 16:49:22 +0200 Ivan Vecera wrote:
> >> +		/* Leave flashing mode */
> >> +		zl3073x_flash_mode_leave(zldev, extack);
> >> +	}
> >> +
> >> +	/* Restart normal operation */
> >> +	rc = zl3073x_dev_start(zldev, true);
> >> +	if (rc)
> >> +		dev_warn(zldev->dev, "Failed to re-start normal operation\n");  
> > 
> > And also we can't really cleanly handle the failure case.
> > 
> > This is why I was speculating about implementing the down/up portion
> > in the devlink core. Add a flag that the driver requires reload_down
> > to be called before the flashing operation, and reload_up after.
> > This way not only core handles some of the error handling, but also
> > it can mark the device as reload_failed if things go sideways, which
> > is a nicer way to surface this sort of permanent error state.  
> 
> This makes sense... The question is if this should reuse existing
> .reload_down and .reload_up callbacks let's say with new devlink action
> DEVLINK_RELOAD_ACTION_FW_UPDATE or rather introduce new callbacks
> .flash_update_down/_up() to avoid confusions.

Whatever makes sense for your driver, for now. I'm assuming both ops
are the same, otherwise you wouldn't be asking? It should be trivial
for someone add the extra ops later, and just hook them both up to the
same functions in existing drivers.