From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27856C433FE for ; Mon, 9 May 2022 19:27:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240637AbiEITb2 (ORCPT ); Mon, 9 May 2022 15:31:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240608AbiEITb2 (ORCPT ); Mon, 9 May 2022 15:31:28 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF5697C277; Mon, 9 May 2022 12:27:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6A202B8190E; Mon, 9 May 2022 19:27:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BC31C385B8; Mon, 9 May 2022 19:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652124451; bh=LHhMugA56ra1E/f4M4s+HXIm7ikQL8aa6G58KTVtBz4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=h2xt4MIT0hq1byYBVWoaJFVZH1PqfmapTHYVbY4QF1GfBw0gWYpkJvffxYVJROp/w o5e5XlseTtAbyczalx8WZma7nau3776eEMiPnAb+aH7DGy0paSceaMMK2NgH7mDaq7 V6qTzsl90AZuCQCvlnnxzD8SWTPrbuwvdWXVVtFaMT3bvb+XpjRevOipjIyd5LJ+QM 5lmV1PyqZUkQhLRASuo/BMjBfrdnF6ogjqVZ5ErYdH/2BTdCsGCeE1sWNtQT8ooI2a 1MGt9OfEic40lzbwntnx56i0TY8f3A/Y94vuuNcULimj4Higp6KJ9f0rpfeGaAwk44 BUgdRk+a2pzvw== Received: by mail-pl1-f179.google.com with SMTP id j14so14800996plx.3; Mon, 09 May 2022 12:27:31 -0700 (PDT) X-Gm-Message-State: AOAM531f9bsYZJMpKqUmdf0NYCNlt6bO0bCfARm12OJf+46qQCGNjslO 06P5XsNNjEfQ5A6fiuh8/3Jh0fXWF5smmndZUQ== X-Google-Smtp-Source: ABdhPJxsHGmg1x9eSAFKq3936wK9SVxFgpdBQ4tMi6tmOw4dHd/EQlYww4Lzlp1GP6qEzY5zGXKq8YCcknR/kaYKZuM= X-Received: by 2002:a17:902:9345:b0:15f:186b:e478 with SMTP id g5-20020a170902934500b0015f186be478mr4219682plp.117.1652124450742; Mon, 09 May 2022 12:27:30 -0700 (PDT) MIME-Version: 1.0 References: <35661036a7e4160850895f9b37f35408b6a29f2f.1652091160.git.robin.murphy@arm.com> In-Reply-To: <35661036a7e4160850895f9b37f35408b6a29f2f.1652091160.git.robin.murphy@arm.com> From: Rob Herring Date: Mon, 9 May 2022 14:27:19 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] iommu/dma: Explicitly sort PCI DMA windows To: Robin Murphy Cc: Joerg Roedel , Will Deacon , Bjorn Helgaas , Linux IOMMU , PCI , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Mon, May 9, 2022 at 5:16 AM Robin Murphy wrote: > > Originally, creating the dma_ranges resource list in pre-sorted fashion > was the simplest and most efficient way to enforce the order required by > iova_reserve_pci_windows(). However since then at least one PCI host > driver is now re-sorting the list for its own probe-time processing, > which doesn't seem entirely unreasonable, so that basic assumption no > longer holds. Make iommu-dma robust and get the sort order it needs by > explicitly sorting, which means we can also save the effort at creation > time and just build the list in whatever natural order the DT had. > > Signed-off-by: Robin Murphy > --- > > v2: Clean up now-unused local variable > > drivers/iommu/dma-iommu.c | 13 ++++++++++++- > drivers/pci/of.c | 8 +------- > 2 files changed, 13 insertions(+), 8 deletions(-) Reviewed-by: Rob Herring