From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-hyperv@vger.kernel.org, Karol Herbst <kherbst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jerry Snitselaar <jsnitsel@redhat.com>,
dri-devel@lists.freedesktop.org, patches@lists.linux.dev,
Laxman Dewangan <ldewangan@nvidia.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-riscv@lists.infradead.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wei Liu <wei.liu@kernel.org>, Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dexuan Cui <decui@microsoft.com>,
Russell King <linux@armlinux.org.uk>,
Jon Hunter <jonathanh@nvidia.com>,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
Danilo Krummrich <dakr@redhat.com>,
nouveau@lists.freedesktop.org,
linux-snps-arc@lists.infradead.org, Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Will Deacon <will@kernel.org>, Sven Peter <sven@svenpeter.dev>,
Haiyang Zhang <haiyangz@microsoft.com>,
Vineet Gupta <vgupta@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Vinod Koul <vkoul@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Robin Murphy <robin.murphy@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-mips@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
asahi@lists.linux.dev, Sudeep Holla <sudeep.holla@arm.com>,
dmaengine@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
Date: Thu, 30 Nov 2023 08:21:35 -0400 [thread overview]
Message-ID: <20231130122135.GG1389974@nvidia.com> (raw)
In-Reply-To: <ZWhuGl1l5V5b+w4P@lpieralisi>
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-hyperv@vger.kernel.org, Karol Herbst <kherbst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jerry Snitselaar <jsnitsel@redhat.com>,
dri-devel@lists.freedesktop.org, patches@lists.linux.dev,
Laxman Dewangan <ldewangan@nvidia.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-riscv@lists.infradead.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wei Liu <wei.liu@kernel.org>, Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dexuan Cui <decui@microsoft.com>,
Russell King <linux@armlinux.org.uk>,
Jon Hunter <jonathanh@nvidia.com>,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
Danilo Krummrich <dakr@redhat.com>,
nouveau@lists.freedesktop.org,
linux-snps-arc@lists.infradead.org, Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Will Deacon <will@kernel.org>, Sven Peter <sven@svenpeter.dev>,
Haiyang Zhang <haiyangz@microsoft.com>,
Vineet Gupta <vgupta@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Vinod Koul <vkoul@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Robin Murphy <robin.murphy@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-mips@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
asahi@lists.linux.dev, Sudeep Holla <sudeep.holla@arm.com>,
dmaengine@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
Date: Thu, 30 Nov 2023 08:21:35 -0400 [thread overview]
Message-ID: <20231130122135.GG1389974@nvidia.com> (raw)
In-Reply-To: <ZWhuGl1l5V5b+w4P@lpieralisi>
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-hyperv@vger.kernel.org, Karol Herbst <kherbst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jerry Snitselaar <jsnitsel@redhat.com>,
dri-devel@lists.freedesktop.org, patches@lists.linux.dev,
Laxman Dewangan <ldewangan@nvidia.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-riscv@lists.infradead.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wei Liu <wei.liu@kernel.org>, Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dexuan Cui <decui@microsoft.com>,
Russell King <linux@armlinux.org.uk>,
Jon Hunter <jonathanh@nvidia.com>,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
Danilo Krummrich <dakr@redhat.com>,
nouveau@lists.freedesktop.org,
linux-snps-arc@lists.infradead.org, Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Will Deacon <will@kernel.org>, Sven Peter <sven@svenpeter.dev>,
Haiyang Zhang <haiyangz@microsoft.com>,
Vineet Gupta <vgupta@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Vinod Koul <vkoul@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Robin Murphy <robin.murphy@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-mips@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
asahi@lists.linux.dev, Sudeep Holla <sudeep.holla@arm.com>,
dmaengine@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
Date: Thu, 30 Nov 2023 08:21:35 -0400 [thread overview]
Message-ID: <20231130122135.GG1389974@nvidia.com> (raw)
In-Reply-To: <ZWhuGl1l5V5b+w4P@lpieralisi>
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-hyperv@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jerry Snitselaar <jsnitsel@redhat.com>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-riscv@lists.infradead.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wei Liu <wei.liu@kernel.org>, Will Deacon <will@kernel.org>,
Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dexuan Cui <decui@microsoft.com>,
Russell King <linux@armlinux.org.uk>,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
nouveau@lists.freedesktop.org,
linux-snps-arc@lists.infradead.org, Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Sven Peter <sven@svenpeter.dev>,
Haiyang Zhang <haiyangz@microsoft.com>,
Vineet Gupta <vgupta@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
David Woodhouse <dwmw2@infradead.org>,
Hector Martin <marcan@marcan.st>,
patches@lists.linux.dev, Vinod Koul <vkoul@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
asahi@lists.linux.dev,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Sudeep Holla <sudeep.holla@arm.com>,
dmaengine@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [Nouveau] [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
Date: Thu, 30 Nov 2023 08:21:35 -0400 [thread overview]
Message-ID: <20231130122135.GG1389974@nvidia.com> (raw)
In-Reply-To: <ZWhuGl1l5V5b+w4P@lpieralisi>
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-hyperv@vger.kernel.org, Karol Herbst <kherbst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jerry Snitselaar <jsnitsel@redhat.com>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
Hanjun Guo <guohanjun@huawei.com>,
linux-riscv@lists.infradead.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wei Liu <wei.liu@kernel.org>, Will Deacon <will@kernel.org>,
Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dexuan Cui <decui@microsoft.com>,
Russell King <linux@armlinux.org.uk>,
Jon Hunter <jonathanh@nvidia.com>,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
Danilo Krummrich <dakr@redhat.com>,
nouveau@lists.freedesktop.org,
linux-snps-arc@lists.infradead.org, Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Sven Peter <sven@svenpeter.dev>,
Haiyang Zhang <haiyangz@microsoft.com>,
Vineet Gupta <vgupta@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
David Woodhouse <dwmw2@infradead.org>,
Hector Martin <marcan@marcan.st>,
patches@lists.linux.dev, Vinod Koul <vkoul@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
asahi@lists.linux.dev,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Sudeep Holla <sudeep.holla@arm.com>,
dmaengine@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
Date: Thu, 30 Nov 2023 08:21:35 -0400 [thread overview]
Message-ID: <20231130122135.GG1389974@nvidia.com> (raw)
In-Reply-To: <ZWhuGl1l5V5b+w4P@lpieralisi>
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
next prev parent reply other threads:[~2023-11-30 12:21 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 01/10] iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops() Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure() Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` [Nouveau] " Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 0:47 ` [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure() Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 3:11 ` Baolu Lu
2023-11-29 3:11 ` Baolu Lu
2023-11-29 3:11 ` [Nouveau] " Baolu Lu
2023-11-29 3:11 ` Baolu Lu
2023-11-29 3:11 ` Baolu Lu
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 05/10] iommu: Mark dev_iommu_priv_set() with a lockdep Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 17:58 ` Robin Murphy
2023-11-29 17:58 ` Robin Murphy
2023-11-29 17:58 ` [Nouveau] " Robin Murphy
2023-11-29 17:58 ` Robin Murphy
2023-11-29 17:58 ` Robin Murphy
2023-11-29 19:04 ` Jason Gunthorpe
2023-11-29 19:04 ` Jason Gunthorpe
2023-11-29 19:04 ` [Nouveau] " Jason Gunthorpe
2023-11-29 19:04 ` Jason Gunthorpe
2023-11-29 19:04 ` Jason Gunthorpe
2023-11-29 0:48 ` [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id() Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` [Nouveau] " Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 3:09 ` Baolu Lu
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 16:23 ` Thierry Reding
2023-11-29 16:23 ` Thierry Reding
2023-11-29 16:23 ` [Nouveau] " Thierry Reding
2023-11-29 16:23 ` Thierry Reding
2023-11-29 16:23 ` Thierry Reding
2023-11-29 19:26 ` Jason Gunthorpe
2023-11-29 19:26 ` Jason Gunthorpe
2023-11-29 19:26 ` [Nouveau] " Jason Gunthorpe
2023-11-29 19:26 ` Jason Gunthorpe
2023-11-29 19:26 ` Jason Gunthorpe
2023-12-01 11:22 ` Thierry Reding
2023-12-01 11:22 ` Thierry Reding
2023-12-01 11:22 ` [Nouveau] " Thierry Reding
2023-12-01 11:22 ` Thierry Reding
2023-12-01 11:22 ` Thierry Reding
2023-11-29 0:48 ` [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [Nouveau] " Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 19:12 ` Jason Gunthorpe
2023-11-29 19:12 ` Jason Gunthorpe
2023-11-29 19:12 ` [Nouveau] " Jason Gunthorpe
2023-11-29 19:12 ` Jason Gunthorpe
2023-11-29 19:12 ` Jason Gunthorpe
2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 12:21 ` Jason Gunthorpe [this message]
2023-11-30 12:21 ` Jason Gunthorpe
2023-11-30 12:21 ` [Nouveau] " Jason Gunthorpe
2023-11-30 12:21 ` Jason Gunthorpe
2023-11-30 12:21 ` Jason Gunthorpe
2023-11-30 14:10 ` Robin Murphy
2023-11-30 14:10 ` Robin Murphy
2023-11-30 14:10 ` [Nouveau] " Robin Murphy
2023-11-30 14:10 ` Robin Murphy
2023-11-30 14:10 ` Robin Murphy
2023-11-30 15:36 ` Jason Gunthorpe
2023-11-30 15:36 ` Jason Gunthorpe
2023-11-30 15:36 ` [Nouveau] " Jason Gunthorpe
2023-11-30 15:36 ` Jason Gunthorpe
2023-11-30 15:36 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231130122135.GG1389974@nvidia.com \
--to=jgg@nvidia.com \
--cc=alyssa@rosenzweig.io \
--cc=aou@eecs.berkeley.edu \
--cc=asahi@lists.linux.dev \
--cc=baolu.lu@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=dakr@redhat.com \
--cc=decui@microsoft.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dwmw2@infradead.org \
--cc=frowand.list@gmail.com \
--cc=guohanjun@huawei.com \
--cc=haiyangz@microsoft.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
--cc=kherbst@redhat.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kys@microsoft.com \
--cc=ldewangan@nvidia.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lpieralisi@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marcan@marcan.st \
--cc=mdf@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=palmer@dabbelt.com \
--cc=patches@lists.linux.dev \
--cc=paul.walmsley@sifive.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sudeep.holla@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=sven@svenpeter.dev \
--cc=thierry.reding@gmail.com \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@kernel.org \
--cc=vkoul@kernel.org \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.