All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>, Christoph Hellwig <hch@lst.de>,
	Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/7] OF: Simplify DMA range calculations
Date: Wed, 29 Nov 2023 20:46:03 -0400	[thread overview]
Message-ID: <20231130004603.GB1394392@ziepe.ca> (raw)
In-Reply-To: <73becf4a75f15662b2dda5fba7cfeacdf3d866f8.1701268753.git.robin.murphy@arm.com>

On Wed, Nov 29, 2023 at 05:42:59PM +0000, Robin Murphy wrote:
> Juggling start, end, and size values for a range is somewhat redundant
> and a little hard to follow. Consolidate down to just using inclusive
> start and end, which saves us worrying about size overflows for full
> 64-bit ranges (note that passing a potentially-overflowed value through
> to arch_setup_dma_ops() is benign for all current implementations, and
> this is working towards removing that anyway).

In iommu code I've been trying to use consistent language with other
parts of the kernel like interval tree and maple tree:

 * In this file the term 'last' indicates an inclusive and closed interval, eg
 * [0,0] refers to a single PFN. 'end' means an open range, eg [0,0) refers to
 * no PFNs.

Here I think you've swapped end to mean last?

Regardless the change looks correct

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>, Christoph Hellwig <hch@lst.de>,
	Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/7] OF: Simplify DMA range calculations
Date: Wed, 29 Nov 2023 20:46:03 -0400	[thread overview]
Message-ID: <20231130004603.GB1394392@ziepe.ca> (raw)
In-Reply-To: <73becf4a75f15662b2dda5fba7cfeacdf3d866f8.1701268753.git.robin.murphy@arm.com>

On Wed, Nov 29, 2023 at 05:42:59PM +0000, Robin Murphy wrote:
> Juggling start, end, and size values for a range is somewhat redundant
> and a little hard to follow. Consolidate down to just using inclusive
> start and end, which saves us worrying about size overflows for full
> 64-bit ranges (note that passing a potentially-overflowed value through
> to arch_setup_dma_ops() is benign for all current implementations, and
> this is working towards removing that anyway).

In iommu code I've been trying to use consistent language with other
parts of the kernel like interval tree and maple tree:

 * In this file the term 'last' indicates an inclusive and closed interval, eg
 * [0,0] refers to a single PFN. 'end' means an open range, eg [0,0) refers to
 * no PFNs.

Here I think you've swapped end to mean last?

Regardless the change looks correct

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-11-30  0:46 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 17:42 [PATCH 0/7] dma-mapping: Clean up arch_setup_dma_ops() Robin Murphy
2023-11-29 17:42 ` Robin Murphy
2023-11-29 17:42 ` [PATCH 1/7] OF: Retire dma-ranges mask workaround Robin Murphy
2023-11-29 17:42   ` Robin Murphy
2023-11-30 14:46   ` Rob Herring
2023-11-30 14:46     ` Rob Herring
2023-11-29 17:42 ` [PATCH 2/7] OF: Simplify DMA range calculations Robin Murphy
2023-11-29 17:42   ` Robin Murphy
2023-11-30  0:46   ` Jason Gunthorpe [this message]
2023-11-30  0:46     ` Jason Gunthorpe
2023-11-30 14:56   ` Rob Herring
2023-11-30 14:56     ` Rob Herring
2023-11-29 17:43 ` [PATCH 3/7] ACPI/IORT: Handle memory address size limits as limits Robin Murphy
2023-11-29 17:43   ` Robin Murphy
2023-11-30  0:39   ` Jason Gunthorpe
2023-11-30  0:39     ` Jason Gunthorpe
2023-12-11 13:27   ` Will Deacon
2023-12-11 13:27     ` Will Deacon
2023-12-11 15:01     ` Robin Murphy
2023-12-11 15:01       ` Robin Murphy
2023-12-11 15:30       ` Will Deacon
2023-12-11 15:30         ` Will Deacon
2023-12-11 15:36         ` Jason Gunthorpe
2023-12-11 15:36           ` Jason Gunthorpe
2023-12-11 15:37         ` Robin Murphy
2023-12-11 15:37           ` Robin Murphy
2023-12-11 15:39         ` Mark Rutland
2023-12-11 15:39           ` Mark Rutland
2023-12-11 16:13           ` Robin Murphy
2023-12-11 16:13             ` Robin Murphy
2023-12-11 15:37       ` Mark Rutland
2023-12-11 15:37         ` Mark Rutland
2023-11-29 17:43 ` [PATCH 4/7] dma-mapping: Add helpers for dma_range_map bounds Robin Murphy
2023-11-29 17:43   ` Robin Murphy
2023-11-29 20:40   ` Jason Gunthorpe
2023-11-29 20:40     ` Jason Gunthorpe
2023-11-30  6:11   ` kernel test robot
2023-11-30  6:11   ` kernel test robot
2023-12-04  8:43   ` Christoph Hellwig
2023-12-04  8:43     ` Christoph Hellwig
2023-11-29 17:43 ` [PATCH 5/7] iommu/dma: Make limit checks self-contained Robin Murphy
2023-11-29 17:43   ` Robin Murphy
2023-11-29 20:43   ` Jason Gunthorpe
2023-11-29 20:43     ` Jason Gunthorpe
2023-11-29 17:43 ` [PATCH 6/7] iommu/dma: Centralise iommu_setup_dma_ops() Robin Murphy
2023-11-29 17:43   ` Robin Murphy
2023-11-29 20:50   ` Jason Gunthorpe
2023-11-29 20:50     ` Jason Gunthorpe
2023-11-29 17:43 ` [PATCH 7/7] dma-mapping: Simplify arch_setup_dma_ops() Robin Murphy
2023-11-29 17:43   ` Robin Murphy
2023-11-30  5:23   ` kernel test robot
2023-12-04  8:44   ` Christoph Hellwig
2023-12-04  8:44     ` Christoph Hellwig
2023-12-04 12:54     ` Robin Murphy
2023-12-04 12:54       ` Robin Murphy
2023-11-29 20:36 ` [PATCH 0/7] dma-mapping: Clean up arch_setup_dma_ops() Jason Gunthorpe
2023-11-29 20:36   ` Jason Gunthorpe
2023-12-01 13:07   ` Robin Murphy
2023-12-01 13:07     ` Robin Murphy
2023-12-01 13:57     ` Jason Gunthorpe
2023-12-01 13:57       ` 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=20231130004603.GB1394392@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=aou@eecs.berkeley.edu \
    --cc=baolu.lu@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=decui@microsoft.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=frowand.list@gmail.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=guohanjun@huawei.com \
    --cc=haiyangz@microsoft.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kernel@xen0n.name \
    --cc=kys@microsoft.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lpieralisi@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=sudeep.holla@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=vgupta@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.