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::342; helo=mail-wm1-x342.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 ED248211B6C26 for ; Fri, 1 Feb 2019 07:18:23 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id d15so6504344wmb.3 for ; Fri, 01 Feb 2019 07:18:23 -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=PCsnIOwAY5kdtbm4voN4tkIEnGJfBYOgZq2Z9HhPNyw=; b=SUqqIh92dmWDzCbs7lhWb4c4PCZ+qGThRvOBkQ+IyMZ3bJuOSAxH8VlQzx2cvUfrfL UM8ki2FEN8HZ3W5sz7BK4VGjTIjwxC83YMd0oP/G0UWssIUy2g7kQemsWMJh5Q1SnsH9 p+0l1paYA6mnr+iNl5bq18I2/4OM0R9dzEkHU= 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=PCsnIOwAY5kdtbm4voN4tkIEnGJfBYOgZq2Z9HhPNyw=; b=IQfUmYj365U4UZfblqAJoJrCw9IUypIbC7nMsNNh+sdyV9xCiMG6gSoGoLyDp7drmG 9YAYNHwqcL/n3cRkjrxyD6CuzSie43IIdOPo4pC2gQ5zFwULe09sohWJZ+x+/cM0qeV5 PqnwVdbNCtYT2oeskyzHOV8aLdrqicsVXnt6m/mONXc2iaPioRT6UrsUYvlBdoIJvuy0 hmGFkh82ReeREmx5tGOr2xXvn62YvJElDIdXuAcpaWM2hPObkAXsxyM12POMVuVDHLD/ bIJkpWb2lHGZT/XdXxR4k84Dnv/TgCZZXH95CSRt1VjmQnoTQjEM1gceoYJmcxva7vpZ xSgg== X-Gm-Message-State: AHQUAubvp4B7xd9kSLe8i4nX9kQYHXaAP6gtC5kpzGT95BKQhKj5Q2Se Kj86+1Ekxsljd1QKa6aYHqhwnw== X-Google-Smtp-Source: AHgI3IblSKgzr9vvmRKvjVSDMKxKYIcKGCDQWNYIhaWVAasrWzeeV0dpPySlP8PQ4ZHMy+uHXLJgTw== X-Received: by 2002:a1c:81ca:: with SMTP id c193mr3037567wmd.66.1549034301456; Fri, 01 Feb 2019 07:18:21 -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 c129sm2315162wma.48.2019.02.01.07.18.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Feb 2019 07:18:20 -0800 (PST) Date: Fri, 1 Feb 2019 15:18:18 +0000 From: Leif Lindholm To: Pete Batard Cc: Laszlo Ersek , Andrew Fish , Ard Biesheuvel , "edk2-devel@lists.01.org" , Mike Kinney Message-ID: <20190201151818.bjy6s4fihw7g4gmk@bivouac.eciton.net> 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> <549d7ea6-f995-e2fc-a265-91d2d5b3ef46@akeo.ie> MIME-Version: 1.0 In-Reply-To: <549d7ea6-f995-e2fc-a265-91d2d5b3ef46@akeo.ie> User-Agent: NeoMutt/20170113 (1.7.2) 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 15:18:24 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please assume that for now. If you're ready to resubmit and we change our mind, I'll do the rework. Regards, Leif On Fri, Feb 01, 2019 at 10:28:32AM +0000, Pete Batard wrote: > 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 > > >