From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::443; helo=mail-wr1-x443.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4699D2194D3AE for ; Mon, 12 Nov 2018 03:25:29 -0800 (PST) Received: by mail-wr1-x443.google.com with SMTP id e3-v6so8914089wrs.5 for ; Mon, 12 Nov 2018 03:25:28 -0800 (PST) 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:in-reply-to:user-agent; bh=PBR8CL1d5Yf2zv4LVa/d+MQq9qQbN3PH3HfKy6TBBXU=; b=Xd37M9B5wh63qpMwM9Wj4S1zy6Eic2DGf6P5jTtwDVyIX1Fo0K1IwTQ5AGNWXOyJmp GQW4wRH07nCn8lqi8GQyKZAEhDknIe27unRXG40SIxVkfQOXxfdnZlvp9ZwuKHfvrqar XQP9gzFWUEwcYhjSrA0Vjn2ECIeUceaz3/NeM= 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:in-reply-to:user-agent; bh=PBR8CL1d5Yf2zv4LVa/d+MQq9qQbN3PH3HfKy6TBBXU=; b=Dm/188uwjI/H/NNizlS2drJF2oltARaRGcJGsF7XrU/jfhEBmVv2pMtRA6nJ/SFDVW TPIzSRgR0fvkr/xo7Gd+UZQLGFe0/xunh6Sa/UNlHDLw9JUctP3Y4djArQrhpVgnlMy2 /5i9+oCHaRz6enIa2DosWksPcLaNrMfN+AwvoaKBRBazNYP0D4bth7BZkdVo/nW5eBkP aa7TfHde30OJdaKhuynnJSHUkOhlgS8i50zz7M2W1ZA02D3105LrUMhewgKLZRv5Oy/7 vhIJ3M0PRRlLHoeaxBCawygQvYDQGxC3KMVLPdYEwMNRznkGFg/d8n1EGAoeYtVxlvkA X4lQ== X-Gm-Message-State: AGRZ1gLEkW8qRK99TLJnKSVmMNrO3kmpB/5nqO7f1Hk9MiIMatSwx9ZC AAOF/+fwowLRPoEXfdi+BrEung== X-Google-Smtp-Source: AJdET5fkbaj5qM4B6rTTzcptp9rGo7hOmiB48p/WXSIeF8g62JkKDlbFg7LRNQ4rOSVhzQCPHOGErA== X-Received: by 2002:adf:c550:: with SMTP id s16-v6mr606379wrf.264.1542021927392; Mon, 12 Nov 2018 03:25:27 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id q11-v6sm13007842wrj.7.2018.11.12.03.25.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Nov 2018 03:25:26 -0800 (PST) Date: Mon, 12 Nov 2018 11:25:25 +0000 From: Leif Lindholm To: chandni cherukuri Cc: edk2-devel@lists.01.org Message-ID: <20181112112525.vla3bjxfinjpupmg@bivouac.eciton.net> References: <1541410019-1781-1-git-send-email-chandni.cherukuri@arm.com> <1541410019-1781-2-git-send-email-chandni.cherukuri@arm.com> <20181109162918.biighqlpmr3ueesw@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH v2 edk2-platforms 1/5] Platform/ARM/Sgi: Adapt to changes in system-id DT node. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 11:25:29 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline +edk2-devel On Mon, Nov 12, 2018 at 04:28:35PM +0530, chandni cherukuri wrote: > On Fri, Nov 9, 2018 at 9:59 PM Leif Lindholm wrote: > > > > On Mon, Nov 05, 2018 at 02:56:55PM +0530, Chandni Cherukuri wrote: > > > The 'system-id' node of HW_CONFIG device tree has been updated to have > > > a new property 'config-id' to hold the platform configuration value. > > > Prior to this, configuration ID value was represented by the the upper > > > four bits of the 'platform ID' property value but it now has a seperate > > > property of its own in the 'system-id' node. So adapt to these changes > > > in the 'system-id' node. > > > > This gets a bit hairy semantically: > > - PlatformId used to be the contents of node "platform-id" > > - PlatformId is now the union of the lower 28 bits of node > > "platform-id" and the 4 bottom bits of new node "config-id", > > - The result is still called PlatformId. > > > > Is there some better way of describing this? Should the function name > > change? > > > Before the 'system-id' node is represented as - > system-id { > platform-id = <>; /* Consists of both PART NUMBER and Configuration ID */ > } > > Earlier for the 'platform-id' property, the upper 4 bits consisted of > the configuration > number and the lower 12 bits consisted of the part number of the platform but > now that value has been split across two properties ('platform-id' and > 'config-id') > , 'platform-id' consists of the part number and 'config-id' consists > of the configuration > number of the platform. > > Currently the system-id node is represented as below - > system-id { > platform-id = <>; /* PART NUMBER */ > config-id = <>; /* Configuration ID */ > } > > So even now the contents of the 'PlatformId' is still the same. To > account for the > changes done in the 'system-id' device tree node the code as been > modified so that > the 'PlatformId' variable still consists of both the PART NUMBER and > Configuration ID > of the platform. OK, so given that (excellent) explanation, it sounds to me like the function should be renamed (more below). > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Chandni Cherukuri > > > --- > > > .../SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c | 19 ++++++++++++++++++- > > > > Can you ensure you generate patches in accordance with the > > instructions at > > https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23 > > ? > > > ok. will generate the patches accordingly. > > > > 1 file changed, 18 insertions(+), 1 deletion(-) > > > > > > diff --git a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c > > > index 081d329..8b6c71b 100644 > > > --- a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c > > > +++ b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c > > > @@ -42,6 +42,8 @@ GetSgiPlatformId ( > > > > Since this is changing what the return value of the function means, > > can the function description comment be updated as well? > > > The return value of the function is still the same as before. The function > returns the 'PlatformId' variable in which the upper 4 bits consists of the > Configuration ID and the lower 12 bits consists of the part number of > the platform. Yes, but the fact that the return value is numerically the same is irrelevant; it now means something different than what it used to be. Based on your explanation above, I would suggest a more appropriate name for this function would now be GetSgiSystemId. *however* ... it also makes me question why this change was made in this way? If we're changing the underlying data structure, why are we not also changing SGI_PLATFORM_DESCRIPTOR to reflect this? If we do that, we can then get rid of the opposite shifting/masking in ArmSgiPkgEntryPoint() and nuke SGI_PART_NUM_MASK, SGI_CONFIG_SHIFT and SGI_CONFIG_MASK completely. > > > CONST VOID *HwCfgDtBlob; > > > SGI_HW_CONFIG_INFO_PPI *HwConfigInfoPpi; > > > EFI_STATUS Status; > > > + UINT32 PlatformId; > > > + UINT32 ConfigId; > > > > > > Status = PeiServicesLocatePpi (&gHwConfigDtInfoPpiGuid, 0, NULL, > > > (VOID**)&HwConfigInfoPpi); > > > @@ -69,7 +71,22 @@ GetSgiPlatformId ( > > > return 0; > > > } > > > > > > - return fdt32_to_cpu (*Property); > > > + PlatformId = fdt32_to_cpu (*Property); > > > + > > > + Property = fdt_getprop (HwCfgDtBlob, Offset, "config-id", NULL); > > > + if (Property == NULL) { > > > + DEBUG ((DEBUG_ERROR, "Config Id is NULL\n")); > > > + return 0; > > > + } > > > + > > > + ConfigId = fdt32_to_cpu (*Property); > > > + > > > + // Concatenate the value of config ID into the platform ID value with > > > + // config ID occupying the upper 4 bits of platform ID. > > > + ConfigId = ConfigId & SGI_CONFIG_MASK; > > > > We are here silently discarding 28 bits of data that need to be set to > > 0 for the below operation to make sense. > > I think an ASSERT might be in order. > > > okay. will introduce an assert if the upper 28 bits of data for > ConfigId is not 0. > > > I also note that we've neither looked at nor cleared the top four bits > > of PlatformId. > > > Okay. will introduce an ASSERT if the upper 4 bits of PlatformId id not 0. > > > > + PlatformId = PlatformId | (ConfigId << SGI_CONFIG_SHIFT); > > > + > > > + return PlatformId; > > > > I would be happier with just the return statement - reusing the > > PlatformId variable does not simplify anything. > > > I did not understand this point. Merely that return PlatformId | (ConfigId << SGI_CONFIG_SHIFT); is easier to read than (and hence preferable to) PlatformId = PlatformId | (ConfigId << SGI_CONFIG_SHIFT); return PlatformId; . But depending on your take on my comments above, this may now be irrelevant. Regards, Leif > > / > > Leif. > > > > > } > > > > > > /** > > > -- > > > 2.7.4 > > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel