From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mx.groups.io with SMTP id smtpd.web11.7162.1587651526841245442 for ; Thu, 23 Apr 2020 07:18:47 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=gdz5lga0; spf=pass (domain: nuviainc.com, ip: 209.85.221.65, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f65.google.com with SMTP id j2so7045306wrs.9 for ; Thu, 23 Apr 2020 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6p26Jg3vCPP3/5T1cVgDoKallw4+6XvDXamO6pgGut8=; b=gdz5lga04nKkfO00V6h3jhGBuDTQyaO2Xgm4HLK0OYBfY9nPmTAq7wRG+74lbF10MB xN7BHYZIMUe8k9sBMweLwivQrAO0oaCrFXrWauGJl8x8A5P9XCp9S+tHC7aEO+gQjv8U 366/RFEM0PY+bmVDjf9sd+uOsLevnfL4hej4SgLji8SEToJnnGz3sGBjLMNCXfxsOECd 91kxMkNBMUjIKoieQOR1+azyeKZDS7ftWAz3Wb/j3CtuBF7porBAVarL2qMNGM+ig2TS lcn4hmVvjvwAlMyRwnxdEFi5SzZqbJiyqYnhJdQlAKzDCLx4e8wLvo1QYYzuVR6c82uT I2JA== 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=6p26Jg3vCPP3/5T1cVgDoKallw4+6XvDXamO6pgGut8=; b=Z2EfSIuR/Vm08BTh/5f91xyC3Wt3I5nacxLinxha1CzJgaUxCjgJ9W7wLw5enDc5lW b0JvCV2Tl39NeEWJJe3Cqx6Po/TEEBCSW0yuSkmKm45DwXO20KCUk6F4mwO2Lyavt0nJ RcFr/2MYsHiaXs8NR8KGYZusOlXrz7zr6/8WxxigoOwgzQBdDAkBT0UHYZss9NK3YWL4 NRJMRYlyaXuF6Fk7F8x4F8EgQyFmo2/9kPm1X+/76vVwv9WjxitrFeNtLFQDPNSz6gNJ /iBvdgNElnEsRa84zlRe1hDeWcRHAB8067MTmOOXqOAbnkG+6LE+DuVQnboUTV5oY2hQ +9TQ== X-Gm-Message-State: AGi0PuYbmeqNLG+yjYP8+ILaUKfv5MFDXBntQDGKNIMjLmIgkYLeLJ5a +dXJJFQ+p+1xUD3ziE18oEA92w== X-Google-Smtp-Source: APiQypKOrS/GTPdtMm0BJkDQTUWITZQ4ru5tyHGEmqcJBgwzfcbYouxUs7P10KxV5zDtcRJ9QbshnQ== X-Received: by 2002:adf:f98e:: with SMTP id f14mr5173169wrr.253.1587651525371; Thu, 23 Apr 2020 07:18:45 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id q10sm3743670wrv.95.2020.04.23.07.18.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2020 07:18:44 -0700 (PDT) Date: Thu, 23 Apr 2020 15:18:42 +0100 From: "Leif Lindholm" To: "Pankaj Bansal (OSS)" Cc: Meenakshi Aggarwal , Michael D Kinney , "devel@edk2.groups.io" , Varun Sethi , Samer El-Haj-Mahmoud , Jon Nettleton , Ard Biesheuvel Subject: Re: [PATCH edk2-platforms v3 16/24] Silicon/NXP: Add Chassis2 Package Message-ID: <20200423141842.GF14075@vanye> References: <20200415121342.9246-1-pankaj.bansal@oss.nxp.com> <20200415121342.9246-17-pankaj.bansal@oss.nxp.com> <20200423102714.GW14075@vanye> <20200423115707.GB14075@vanye> <20200423120537.GC14075@vanye> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 23, 2020 at 13:41:14 +0000, Pankaj Bansal (OSS) wrote: > > > > > > The intended usage model for IoAccessLib is to retrieve the function > > > > > > pointer struct once and then always refer to it. Since this is a > > > > > > library, we could have a CONSTRUCTOR function (specified in the .inf) > > > > > > > > > > I had thought of this, but decided against it because of this reason: > > > > > The order of Library constructor call for a module cannot be guaranteed. > > > > > https://edk2.groups.io/g/devel/message/57254 is an good example of > > this. > > > > > BaseDebugLibSerialPortConstructor would need to depend on > > > > ChassisLibConstructor, > > > > > to retrieve the UART clock frequency. If the constructor calls are not > > > > guaranteed, BaseDebugLibSerialPortConstructor > > > > > would fail and it would cause ASSERT due to ASSERT_RETURN_ERROR > > > > (Status) > > > > > > > > If this is a problem (and I recall Ard pointing out some shortcomings > > > > in the dependency handling in the past), we can solve this with an > > > > explicit initialisation call in the SoC or platform init code. > > > > > > You mean put ChassisLibConstructor() call in SerialPortInitialize () ? > > > > Or before the call to SerialPortInitialize in ChassisInit. > > But SerialPortInitialize would be called from each module. Why would multiple modules need to initialize the serial port? > Each module that has SerialPort and ChassiLib linked to it would have a > local copy of mDcfgOps, which needs to be initialized. On the surface it makes more sense for the function that initializes mmio accessors for chassis to be in the chassis initialization function. In the current tree I can only see one user of SerialPortLib and one of ChassisLib - but you are suggesting there will be several per platform? If so, A better splution may ne to consider wrapping DcfgRead32/DcfgWrite32 in a protocol instead of depending on the ChassisLib. / Leif