From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=2a00:1450:4864:20::542; helo=mail-ed1-x542.google.com; envelope-from=pete@akeo.ie; receiver=edk2-devel@lists.01.org Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 DF18F211C6067 for ; Fri, 1 Feb 2019 02:28:37 -0800 (PST) Received: by mail-ed1-x542.google.com with SMTP id d39so4975691edb.12 for ; Fri, 01 Feb 2019 02:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ALgO0CAYII3+bYjAkwVa0fSef+0B7tcBSkvIP2qKL4I=; b=1m11HcqUmD4W47g37bQlVkx6XOIRBEd5auJ2CrwF5G5gJcVr/h3Rqtqxc0G83Y5GbV oGwIK1bwEtm2i0FCKqS/li7/eMGAyzUJIft5G6hBFr7OpDALGdQQU8mqktnggzimsW7f ou/xyvOTeiz8pWoLkhEbqDzkwST/U3uty58LYFZjI+kdFgduBGENqZ3t0atAFsJJMWqk OEbOI03NnqN3QpnZfDmylLotCMFZSPpUIFFKcppTSrmhsoliT1doTx7HNRacmW569Ncl xHIPuz+WWy30yIgxJ9COlRHMpr0d5VhZMkS73Z0oFBiu/j888QtCJ/3KPPT74hKDUrLd sK8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ALgO0CAYII3+bYjAkwVa0fSef+0B7tcBSkvIP2qKL4I=; b=hO7HyVdqBEF0iweTbTf59hfwGlmKXGSL9eeQUCLxVNCvAoiqw/pXxt4KdWoJHAwEbu qSJ3WGkMsR/qStFVnXDeEt7eLMJj3yexGb/iTTx84yquuZw7eGjI5y1dMkKYVs+hoiEc lnOazenhlUS7VmqNsUKYsCcO4zESobiTErxhwFe3lO9G5j25KFdRSjrLRLCBCU+7Fy2T 7FZ6tnhY/SwrajWn+o2M+TvNifUw6UEaD5x6/aq0LVnsxt2ldmERKRp+5tAkVXv7qgfB +MGDWytpw/Vuef1+vv6kkb6ySmE1wDnpWBU9E8W9cENxsJEQ4FzshglCqdFjVFnso4iw Y3ZQ== X-Gm-Message-State: AJcUukeSSCcLIaruR67/gGu2VzWRMwvrhw9jNuOI6Dtd8d/BHq3Ye8Pv fIHD7WdcHYEK/4of85sDXKgl0w== X-Google-Smtp-Source: ALg8bN6P+Gk6bwJEmLbLbtjjRm2fTy9I8u9IbtcN+4CF3auBpf79U1WNptRHXRwJqMM9CG1EAec/tA== X-Received: by 2002:a50:aa9b:: with SMTP id q27mr38270794edc.93.1549016915864; Fri, 01 Feb 2019 02:28:35 -0800 (PST) Received: from [10.0.0.102] ([84.203.95.186]) by smtp.googlemail.com with ESMTPSA id f20sm2043989edf.19.2019.02.01.02.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 02:28:34 -0800 (PST) To: Laszlo Ersek , Andrew Fish , Leif Lindholm Cc: Ard Biesheuvel , "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> <0b06c65c-749c-17eb-6ced-6cde30038d78@redhat.com> From: Pete Batard Message-ID: <549d7ea6-f995-e2fc-a265-91d2d5b3ef46@akeo.ie> Date: Fri, 1 Feb 2019 10:28:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <0b06c65c-749c-17eb-6ced-6cde30038d78@redhat.com> 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 10:28:38 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit All, From the feedback below, I'm going to assert that the current consensus is to keep Bcm2836.h in IndustryStandard/ and therefore, outside of adding an additional description with regards to its purpose, I will keep this patch as-is for v5. If this is not what we want, please let me know. Regards, /Pete On 2019.02.01 08:43, Laszlo Ersek wrote: > 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 >