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::341; helo=mail-wm1-x341.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 4B1562117AE75 for ; Mon, 12 Nov 2018 08:26:27 -0800 (PST) Received: by mail-wm1-x341.google.com with SMTP id r63-v6so9145384wma.4 for ; Mon, 12 Nov 2018 08:26:27 -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=Kzaz4DnvbsHykoUoG5WImLZY7V4mhmenV5MEZRGhh2I=; b=inwPZohSvF3GgqPEZBjPPZP7HAL6WT/4v2KyYBxOk3rLnMXG9vvMvoC/u9bvhK6+7y saXb1SifzIIOaVJ8WWew2IItoJePFbCq14+0PDM3pn/6oTcq69FqFDweYl+cqWCJRUpa LPIGQrV1Y/neLZVYHdprhscyUnoM36XUd7pvs= 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=Kzaz4DnvbsHykoUoG5WImLZY7V4mhmenV5MEZRGhh2I=; b=rg6aL+I7IXvheq/xHGyEAAFWzBkj6cksE7hCH5sXWLLm6DjNtd3YJY39cuMcXdbdWe ouZJSXXiC0a5uWnzFMJ17r8A3l7bt/eLxFLoGyrmgiDEIGQy5M6BywteHzeIY8PSFJPM OS8eRaR3eGKik2AGZlsASeWUX5670lWJMotZ61Z23MFNLzoFBR21Tn+rykrD/jWpvMTT 089bb9h7SiXcwx7mRq0r9GqudifD2K8Qo9GRjIrTpchxMxQqoruqpNi1IuLuD/XkVLtn +mMT8vG1sBkbBbir4AVzrA5c5i56a6AwavrIZUIwAFl6gRJyNZSYecIUmgCMx5AUuMZb 6SHw== X-Gm-Message-State: AGRZ1gK+Faj+vLWuJUxj8Qmuu+kU8Qv2FinLj8d/suY9KOCNc9hvj2il CBTJhCAO8/IrKf/8ujaLBdvjpw== X-Google-Smtp-Source: AJdET5e+NkGSemf5Z9PHPGiOsYAlNQwRbmjrHndFTBEpTdNELU+BgMwg7L/dnZWo2wBPfgH+jHU0qQ== X-Received: by 2002:a1c:770a:: with SMTP id t10-v6mr247963wmi.149.1542039985365; Mon, 12 Nov 2018 08:26:25 -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 y13-v6sm28587640wrq.13.2018.11.12.08.26.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Nov 2018 08:26:24 -0800 (PST) Date: Mon, 12 Nov 2018 16:26:22 +0000 From: Leif Lindholm To: chandni cherukuri Cc: edk2-devel@lists.01.org Message-ID: <20181112162622.kowqjvcktnqukg3h@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> <20181112112525.vla3bjxfinjpupmg@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 16:26:27 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Chandni, On Mon, Nov 12, 2018 at 07:46:38PM +0530, chandni cherukuri wrote: > > > > 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. > > Ok, will change the name of this function in the next version. Thanks. > > *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? > > The intention was to not modify the existing code due to the changes > in the 'system-id' device tree node. And this was done by > concatenating the platform-id and config-id value into one. So this > was the reason for not adding a 'config-id' member in the > SGI_PLATFORM_DESCRIPTOR structure. > > > 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. > > Ok. The preference was given to keep the format and the PlatformID > parsing code as before, which, otherwise would need lot more changes > to the code. Understood. But I think this cleaner end result is well worth the larger patch. > > > > > + 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; > > > > . > Ok. will fix this in the next version. This bit would no longer be needed if the change is made, and the function returns the struct directly. Best Regards, Leif