From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 985DB211C575E for ; Fri, 1 Feb 2019 00:43:37 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4CE43D09; Fri, 1 Feb 2019 08:43:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-49.rdu2.redhat.com [10.10.120.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2E7B60C54; Fri, 1 Feb 2019 08:43:34 +0000 (UTC) To: Andrew Fish , Leif Lindholm Cc: Ard Biesheuvel , Pete Batard , "edk2-devel@lists.01.org" , Mike Kinney References: <20190129162655.3800-1-pete@akeo.ie> <20190129162655.3800-2-pete@akeo.ie> <20190131152425.prahmlg4nh64tuus@bivouac.eciton.net> <20190131195718.lzrj7rf2m62hgor4@bivouac.eciton.net> <0A1F1646-3CE0-4365-94B8-7675BC55AD35@apple.com> From: Laszlo Ersek Message-ID: <0b06c65c-749c-17eb-6ced-6cde30038d78@redhat.com> Date: Fri, 1 Feb 2019 09:43:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0A1F1646-3CE0-4365-94B8-7675BC55AD35@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 01 Feb 2019 08:43:37 +0000 (UTC) Subject: Re: [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver 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: Fri, 01 Feb 2019 08:43:38 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/31/19 22:01, Andrew Fish wrote: > > >> On Jan 31, 2019, at 11:57 AM, Leif Lindholm wrote: >> >> +Andrew, Laszlo, Mike. >> >> On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote: >>> On Thu, 31 Jan 2019 at 16:24, Leif Lindholm wrote: >>>> >>>> On Tue, Jan 29, 2019 at 04:26:33PM +0000, Pete Batard wrote: >>>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>>> Signed-off-by: Pete Batard >>>>> >>>>> Reviewed-by: Ard Biesheuvel >>>>> --- >>>>> Silicon/Broadcom/Bcm283x/Bcm283x.dec | 23 ++ >>>>> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c | 367 ++++++++++++++++++++ >>>>> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf | 48 +++ >>>>> Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h | 72 ++++ >>>> >>>> Another generic comment: "IndustryStandard" is something like ACPI, >>>> SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific >>>> additions to the same). >>> >>> Is that your interpretation? Or is this documented somewhere? >> >> Only in asmuch as it is a clearly descriptive name. >> >>> I could live with Chipset/, and I'm open to other suggestions, but the >>> Library vs Protocol vs IndustryStandard distinction is very useful >>> imo. >> >> It is useful because it is descriptive. >> Pretending that an SoC hardware description or a platform description >> header is an "Industry Standard" is disingenuous. >> >>>> I would be more comfortable with SoC-specific and Platform-specific >>>> include files living directly in Include/. >>> >>> No, don't drop headers in Include/ please. The namespacing is one of >>> the things EDK2 actually gets right (assuming you define the paths >>> correctly in the package .dec file), and I'd hate to start dumping >>> headers at the root level because we cannot make up our minds what to >>> call the enclosing folder. >> >> Mike, Andrew - what is your take on this? >> Is there a formal definition of not only what goes in >> IndustryStandard, but where chipset and platform headers should live >> in the namespace? >> > > Leif, > > I kind of think IndustryStandard as things that have a public spec I think the same. I think any device / interface headers can go under Include/IndustryStandard as long as the interface was explicitly designed for external consumption, and is promised to be stable. I realize some packages have Include/Register too... I find that a bit redundant. Thanks Laszlo