All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tycho Andersen <tycho@kernel.org>
To: Maxwell Doose <m32285159@gmail.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	John Allen <john.allen@amd.com>,
	 Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	 linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Sean Christopherson <seanjc@google.com>,
	Kim Phillips <kim.phillips@amd.com>,
	 Alexey Kardashevskiy <aik@amd.com>,
	Nikunj A Dadhania <nikunj@amd.com>,
	 "Pratik R. Sampat" <prsampat@amd.com>,
	Michael Roth <michael.roth@amd.com>
Subject: Re: [RFC v1 6/6] crypto/ccp: Implement SNP firmware live update
Date: Mon, 4 May 2026 07:57:52 -0600	[thread overview]
Message-ID: <afijY2Q0tEK5BnPs@tycho.pizza> (raw)
In-Reply-To: <DI8PTIGP3I43.JOF10O9FPOMF@gmail.com>

On Sat, May 02, 2026 at 10:18:42PM -0500, Maxwell Doose wrote:
> On Thu Apr 30, 2026 at 11:07 AM CDT, Tycho Andersen wrote:
> > From: "Tycho Andersen (AMD)" <tycho@kernel.org>
> >
> > Put all the previous primitives together to implement SNP firmware
> > live update via DOWNLOAD_FIRMWARE_EX.
> >
> 
> [snip]
> 
> >
> > [1]: https://lore.kernel.org/lkml/20241112232253.3379178-7-dionnaglaze@google.com/
> > Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> > ---
> >  drivers/crypto/ccp/sev-dev.c | 244 ++++++++++++++++++++++++++++++++++-
> >  1 file changed, 243 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> > index b4711bf823e8..e7fe6dbf69c2 100644
> > --- a/drivers/crypto/ccp/sev-dev.c
> > +++ b/drivers/crypto/ccp/sev-dev.c
> > +static int sev_download_firmware_ex(struct sev_device *sev, const u8 *data,
> > +				    u32 size)
> > +{
> > +	struct sev_data_download_firmware_ex sev_data = {0};
> > +	int ret, error = 0, order;
> >
> 
> Why not assign across multiple lines? How about something like:
> 
> int ret, order;
> int error = 0;
> 
> or:
> 
> int ret;
> int order;
> int error = 0;
> 
> Would be better for readability and git blame.

Sure, I'll make the change here and in the other places you noted.

> >  static enum fw_upload_err sev_fw_upload_write(struct fw_upload *fw_upload,
> >  					      const u8 *data, u32 offset,
> >  					      u32 size, u32 *written)
> > {
> >
> 
> [snip]
> 
> >
> > +	old_major = sev->api_major;
> > +	old_minor = sev->api_minor;
> > +	old_build = sev->build;
> > +
> > +	mutex_lock(&sev_cmd_mutex);
> >
> 
> Why not guard(mutex)()? You used it earlier in
> sev_firmware_reinit_if_shutdown().

Because this code calls some functions, including
sev_firmware_reinit_if_shutdown(), that take the lock again. We could
use scoped_guard() I suppose, I can look at that for v2.

It may be useful to do a larger series where we re-think when the
locks are acquired here. It seems like only grabbing them at the top
level entrypoints: ioctl, platform init, firmware update, etc. and
putting lockdep asserts in all the helpers in the file might be
cleaner generally.

Tycho

  parent reply	other threads:[~2026-05-04 13:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 16:07 [RFC v1 0/6] Implement SNP DOWNLOAD_FIRMWARE_EX support Tycho Andersen
2026-04-30 16:07 ` [RFC v1 1/6] crypto/ccp: Hoist kernel part of SNP_PLATFORM_STATUS Tycho Andersen
2026-04-30 16:07 ` [RFC v1 2/6] crypto/ccp: Allow snp_get_platform_data() after SNP init Tycho Andersen
2026-04-30 16:07 ` [RFC v1 3/6] crypto/ccp: Add DOWNLOAD_FIRMWARE_EX message struct Tycho Andersen
2026-04-30 16:07 ` [RFC v1 4/6] crypto/ccp: Reclaim command buffer when the PSP dies Tycho Andersen
2026-04-30 16:07 ` [RFC v1 5/6] crypto/ccp: Register with fw_uploader and always fail Tycho Andersen
2026-04-30 16:07 ` [RFC v1 6/6] crypto/ccp: Implement SNP firmware live update Tycho Andersen
2026-05-03  3:18   ` Maxwell Doose
2026-05-03  3:25     ` Maxwell Doose
2026-05-04 13:57     ` Tycho Andersen [this message]
2026-05-04 18:43       ` Maxwell Doose

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=afijY2Q0tEK5BnPs@tycho.pizza \
    --to=tycho@kernel.org \
    --cc=aik@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=john.allen@amd.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m32285159@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=nikunj@amd.com \
    --cc=prsampat@amd.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.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.