From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by mx.groups.io with SMTP id smtpd.web11.3997.1570751470341745296 for ; Thu, 10 Oct 2019 16:51:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=WhdG3npT; spf=pass (domain: linaro.org, ip: 209.85.128.66, mailfrom: leif.lindholm@linaro.org) Received: by mail-wm1-f66.google.com with SMTP id v17so8396049wml.4 for ; Thu, 10 Oct 2019 16:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=jy6EhsDBPzfklnT9KL264RnXH0ounuFt2KH5rNiWfzU=; b=WhdG3npTfhA0wWetd+smxanQNqAPN0oVqMUDvaRyaJ+oyQVU825mKHM/y8rczrx9Pk 1YI2Qv9a5JHVRxn/wb6pFl61yV/fahOgzoyMj0RrrVe6msHFNSjnEQgV5CgZizRFXBgq Q+B1LY9fTbmrTdsWhjHeQD2HXrgUE8pYcGdTfLoWiitrIHDsRnwW0UZDqRN7zbyTyZqZ OmSPF3KdistSF+ywFeRYB2XCrZnMTyqc7QpMcedRCrLIzOMtONB3sg5tTsfKHhquVi1z xueHDCyz8pMYAptXaZHG4IiXSfiKSXzzt4E/77taq5fJUtko58KatKEZg33oBTonxL33 5xFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=jy6EhsDBPzfklnT9KL264RnXH0ounuFt2KH5rNiWfzU=; b=ejfMrzhgCMUVKfNEcrs4TS/jSxzNQ8qCNuncQ5v5Roujex3hlM/KCgxU+qiHQ8HJsC +pnBFU8alo/1bk69jh5kHvzHZZwz6iRrct/BJ31BPacvYh6alB41J+RUAksO8DBeMWfS AIjMNLTZ17TTY1hmeLP+Uttkb7+gfgKSmNBTTK2tFgMhtFDcaPA9DOx5LtE9NIFFy82d v+NMltk4wXzi6sVsf7XdpPLghAhVspAEpe+oD0C95yhBEELgeR3UPk776BLG0ZCrLNL5 hQIOaMT7BifZ07IeFrXp+n7382hxhNOSKFSdsz8fDZiMNwEQKM47kr9vJufpxAuwaixH STKQ== X-Gm-Message-State: APjAAAVizdLGYDRrLlBFUyC2AemD5TcoNiXkKyGsrYDtAALL2M1jIWE/ 2U+Pc+/QJAgPULZlDjLyO59qvw== X-Google-Smtp-Source: APXvYqxN1THa4/5evgzzm83cL3s7xy1Yp7znDDfzpv6ckeVoj8FdQHlg8zC9PK5dwGK5LTR6RTdamQ== X-Received: by 2002:a05:600c:10ce:: with SMTP id l14mr761066wmd.102.1570751468722; Thu, 10 Oct 2019 16:51:08 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id i1sm8044057wmb.19.2019.10.10.16.51.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2019 16:51:08 -0700 (PDT) Date: Fri, 11 Oct 2019 00:51:06 +0100 From: "Leif Lindholm" To: Marcin Wojtas Cc: edk2-devel-groups-io , Ard Biesheuvel , "jsd@semihalf.com" , Grzegorz Jaszczyk , Kostya Porotchkin , Patryk Duda Subject: Re: [edk2-platforms: PATCH v3 8/9] Marvell/Drivers: SmbiosPlatformDxe: Load SMBIOS strings from PCD Message-ID: <20191010235106.GZ25504@bivouac.eciton.net> References: <1570686139-25182-1-git-send-email-mw@semihalf.com> <1570686139-25182-9-git-send-email-mw@semihalf.com> <20191010230430.GX25504@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Oct 11, 2019 at 01:33:49AM +0200, Marcin Wojtas wrote: > Hi Leif, > > pt., 11 paź 2019 o 01:04 Leif Lindholm napisał(a): > > > > On Thu, Oct 10, 2019 at 07:42:18AM +0200, Marcin Wojtas wrote: > > > From: Patryk Duda > > > > > > This patch implements convenient way of changing strings included > > > in SMBIOS Table1, Table2, Table3. > > > > > > Strings can be altered by defining following PCDs: > > > gMarvellTokenSpaceGuid.PcdProductManufacturer > > > gMarvellTokenSpaceGuid.PcdProductPlatformName > > > gMarvellTokenSpaceGuid.PcdProductVersion > > > gMarvellTokenSpaceGuid.PcdProductSerial > > > > > > This patch adds also limit for length of string which can be increased > > > if necessary in future. > > > > > > Signed-off-by: Patryk Duda > > > --- > > > Silicon/Marvell/Marvell.dec | 6 ++ > > > Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 4 + > > > Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 79 +++++++++++++++++--- > > > 3 files changed, 78 insertions(+), 11 deletions(-) > > > > > > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec > > > index d337d3e..a84b056 100644 > > > --- a/Silicon/Marvell/Marvell.dec > > > +++ b/Silicon/Marvell/Marvell.dec > > > @@ -169,6 +169,12 @@ > > > gMarvellTokenSpaceGuid.PcdPciEAhci|{ 0x0 }|VOID*|0x3000034 > > > gMarvellTokenSpaceGuid.PcdPciESdhci|{ 0x0 }|VOID*|0x3000035 > > > > > > +#Platform description > > > + gMarvellTokenSpaceGuid.PcdProductManufacturer|"Marvell \0"|VOID*|0x50000100 > > > + gMarvellTokenSpaceGuid.PcdProductPlatformName|"Marvell Development Board \0"|VOID*|0x50000101 > > > + gMarvellTokenSpaceGuid.PcdProductSerial|"Serial Not Set \0"|VOID*|0x50000103 > > > + gMarvellTokenSpaceGuid.PcdProductVersion|"Revision unknown \0"|VOID*|0x50000102 > > > + > > > > I'm not too pleased about this random number of spaces. I'm cool with > > the strings, but they should be treated as such, not magical data > > structures. > > In v4 the trailing spaces will be removed from the defaults (as well as "\0"). > > > > +STATIC > > > +VOID > > > +MvSmbiosCopyStrings ( > > > + VOID > > > + ) > > > +{ > > > + EFI_STATUS Status; > > > + > > > + ASSERT (AsciiStrnLenS ((CHAR8 *)PcdGetPtr (PcdProductManufacturer), > > > + MV_SMBIOS_STRING_MAX_SIZE) < MV_SMBIOS_STRING_MAX_SIZE); > > > + ASSERT (AsciiStrnLenS ((CHAR8 *)PcdGetPtr (PcdProductPlatformName), > > > + MV_SMBIOS_STRING_MAX_SIZE) < MV_SMBIOS_STRING_MAX_SIZE); > > > + ASSERT (AsciiStrnLenS ((CHAR8 *)PcdGetPtr (PcdProductVersion), > > > + MV_SMBIOS_STRING_MAX_SIZE) < MV_SMBIOS_STRING_MAX_SIZE); > > > + ASSERT (AsciiStrnLenS ((CHAR8 *)PcdGetPtr (PcdProductSerial), > > > + MV_SMBIOS_STRING_MAX_SIZE) < MV_SMBIOS_STRING_MAX_SIZE); > > > > Especially given the current design, these ASSERTs seem a bit > > ... unhelpful. In fact, this whole MAX_SIZE thing seems ... restricted > > by the implementation, not by external constraints. What is the > > benefit? Not having to do a bunch of pointer conversions at > > SetVirtualAddressMap? > > > > The default static tables require constant initializers and the > placeholders should have some predefined size in current approach. So > max of 32 characters was picked and with the asserts, ensuring the > user will not exceed it. Do you think they should be removed? Oh, you're saying this is basically "TO BE FILLED BY OEM"? *yurgh*. I still say it's horrible, but not more horrible than most existing platforms. Nevertheless, the arbitrary size should be something defined by the code generating the tables - it shouldn't depend on what's in the .dec (or more usefully, the .dsc). I also feel that if it is effectively "TO BE FILLED BY OEM", it would be better if it said that than something that looks like it may be proper names. I would also prefer a compilation failure over an ASSERT if the string ended up not fitting. Best Regards, Leif > Best regards, > Marcin > > > > > > + > > > + Status = AsciiStrCpyS (mSysInfoManufacturer, > > > + MV_SMBIOS_STRING_MAX_SIZE, > > > + (CHAR8 *)PcdGetPtr (PcdProductManufacturer)); > > > + ASSERT_EFI_ERROR (Status); > > > + Status = AsciiStrCpyS (mSysInfoProductName, > > > + MV_SMBIOS_STRING_MAX_SIZE, > > > + (CHAR8 *)PcdGetPtr (PcdProductPlatformName)); > > > + ASSERT_EFI_ERROR (Status); > > > + Status = AsciiStrCpyS (mSysInfoVersion, > > > + MV_SMBIOS_STRING_MAX_SIZE, > > > + (CHAR8 *)PcdGetPtr (PcdProductVersion)); > > > + ASSERT_EFI_ERROR (Status); > > > + Status = AsciiStrCpyS (mSysInfoSerial, > > > + MV_SMBIOS_STRING_MAX_SIZE, > > > + (CHAR8 *)PcdGetPtr (PcdProductSerial)); > > > + ASSERT_EFI_ERROR (Status); > > > +} > > > + > > > +/** > > > Install all structures from the DefaultTables structure > > > > > > @param Smbios SMBIOS protocol > > > @@ -760,6 +815,8 @@ SmbiosInstallAllStructures ( > > > FirmwareMajorRevisionNumber = (PcdGet32 (PcdFirmwareRevision) >> 16) & 0xFF; > > > FirmwareMinorRevisionNumber = PcdGet32 (PcdFirmwareRevision) & 0xFF; > > > > > > + MvSmbiosCopyStrings(); > > > + > > > // > > > // Update Firmware Revision, CPU and DRAM frequencies. > > > // > > > -- > > > 2.7.4 > > >