From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 604F83803D9 for ; Mon, 24 Aug 2026 18:11:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787595117; cv=none; b=LKjEoFV60U9yf/K+KQ3aBy9SK8N4okqZt59jGE1N8aFBXQhSqQuzuVGYjB2XyjcQ8RdEZy+hvd259GtT7t5RF7XZxSbzOegdFRgohybCANw+2m1lan60gvtZVv4+vKvJsokvhLImmCVeQte/H2uMFXLt0Lwkxegxq3IL1OtpG+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787595117; c=relaxed/simple; bh=vgC/Nw6YHaADZa/IxWdXFcfTV8pok/WBDkFchgUIjKw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iy9tTL3zUkwKj5EhIlT+QauZ8c4hu4gWDBShAmK8s0/AyPUbqHMJAdDcVvKUSSbR6TgDq9tJGCXmmLUhaN5PigTD/42Qf1T4yYtwn14IgPWeMqgZvEyBif9e3Y4lJMh0fZMXFBMQFX7tJoy4I4itZohDigGYuGMCdGPUAcltuPk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EnsPyuIy; arc=none smtp.client-ip=209.85.208.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EnsPyuIy" Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-6a082b3671fso6264521a12.3 for ; Mon, 24 Aug 2026 11:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787595113; x=1788199913; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0mwy+LUPZKf1Yv1+uPQ52eOzsbkTlYKsOl/zfBams6E=; b=EnsPyuIyA4w4d6nuiac9IYyKmpXf8kh1vZDi7pe9gQQKu6GIGhAQzZC17QyMvIXXIp N3PycUxxtMJMF8uFzytRW1mYcJxRJsITukVR10TPJvBqap71kuzQnkFxREl6YDtB8aMh IRZioZcLAoIfi953EidgddHr8D23KSYYmN1My5/qnG34kTJNDdSNm0McE5Em4nZMAXEc JT26bWtdV48SKjoY8kOnOd/9WZITpldR2hjZGJ57+48G0RZlWqNIraaLXwaFtzOTkdwS 8tW/Kkaovw3FhEknEh93N76/9+IKFl3Edzu2EaB5u2gXXWgi8fLVsS8KgZ2bFWeJCVe8 Y85w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787595113; x=1788199913; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=0mwy+LUPZKf1Yv1+uPQ52eOzsbkTlYKsOl/zfBams6E=; b=nMi/P641wVsjVAHwFz6W4Ywkos1Escg4ExA1beCS2wwkl44BweLCwmerTJwIABL/Uw teVOqYewfMvNDcmjOy+ZW9/QIQjNhdP8MM+OkFBerJbbOThhQFG2G9/NvAFtx+m+Hj90 lzhmfXqvOdgyNr2VYwKJo/u5dVCxXw03YKT/wLeeM4mUvY0nl2+p/PzZiUebPFN/0hxL PgCBTpIxIbCs+QYFPNKa7HGkd07gEAJosr8dRn/Bfa0Wfswv8+mRS+4QhQpjR0ks7PN9 D/HWwmQMIjstGp+lvsbdUKWvcyymnkkB63k5B30K72OvrHpaXjb6Jj9fmnZqU+qXMLFG +p4g== X-Forwarded-Encrypted: i=1; AHgh+RqSUUYQvWpxi3UEkzQkDyad4RKnMOzCvn//0XO0sYxpxagUBHTU2BLEN+HHhRXdtLwm+ygWE2yypRkA9V4=@vger.kernel.org X-Gm-Message-State: AFuF++nkR5zXxFMEVKSSmcotbYxRgYCHowjj8530RRpAmxvj/WBIsdyD vnJrCXnSSBY1SFYIHY9VSHUDonFiUv2+NEh9jljPfnqCcIomtzbc3/hpUzGxzQ== X-Gm-Gg: AR+sD12tNJ3HlaJhn+1KSNVAkvMEyXatvI8SlkvRYgiphuCrmM1VnVS3eCkxQD84fI2 NqueGWIRcCC8JFiJ9k0ldh+Clu2jHOZV8uuiV1TeFas4c+Ji6xaro6bBVP4pQtDEvUWyqiBvVhY 8k6hBNenHBjb+TbNWgW2L1RXwZ84muwYOAnnUG5A9C+wK2kbYoQDXF5YYYKaKNnclAymIlXxeKu 9QNUXGF++Ckm3StmXKzEgdZClJ12wtqKZv0uq2UPacCHHTmmLAxitqvFvVPVfe6/TXq7nd/1pJk tFnN9D4fKtnVWd9EjtKwU7Z0lHVgV9s4FTTKSErRROTuVD/FTRE/f5IldlWhu0MwImzabk4jntv AcLhDvxyfdtxDvpS81vtOqCdj50M12tGwUj90eMAVnPaef437kt1GuJ9PitBnGuQsj3YKk/p3LH qD8vwVhfpvNn9c5uNd0Fl87FonrxKCG/HaRtCOpAvEwVAgoKMAfqJVYDZlYmwRUm1g5cV+ElVRt zW0jYK0hMN9/kuJ5wIaiT1n0MmtOBE= X-Received: by 2002:a05:6402:249f:b0:6a3:ebe1:c2c2 with SMTP id 4fb4d7f45d1cf-6a42f14dfacmr34920988a12.2.1787595112494; Mon, 24 Aug 2026 11:11:52 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a59dd550bcsm10586910a12.0.2026.08.24.11.11.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 11:11:52 -0700 (PDT) From: Magnus Lindholm To: richard.henderson@linaro.org, mattst88@gmail.com, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org Cc: Magnus Lindholm , Maciej Rozycki Subject: [PATCH v2 1/2] alpha: respect dev->bus_dma_limit as the effective DMA address ceiling Date: Mon, 24 Aug 2026 19:36:53 +0200 Message-ID: <20260824181126.3559638-2-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260824181126.3559638-1-linmag7@gmail.com> References: <20260824181126.3559638-1-linmag7@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The Alpha PCI DMA-mapping code has no way for platform code to cap a device's addressable range below what it claims via dma_set_mask(), even though dev->bus_dma_limit exists precisely for an upstream bridge or bus to impose exactly that kind of constraint. Wire it in as the effective upper bound everywhere an address range gets checked or a DMA window gets selected: - pci_map_single_1() and sg_fill() already bound-check the direct-map window against max_dma; make max_dma itself min_not_zero(dma_mask, bus_dma_limit), and add the same paddr + dac_offset + size - 1 <= max_dma check to their DAC paths, which previously had no bound check at all beyond the bitmask test in pci_dac_dma_supported(). - alpha_pci_map_sg()'s no-IOMMU fallback path (no alpha_mv.mv_pci_tbi) picks up the same ceiling instead of unconditionally using -1. - sg_fill() gains an explicit failure return when there is no IOMMU arena and the direct/DAC paths didn't apply. Previously this relied on max_dma = -1 making the (unchecked) DAC branch always succeed whenever dac_allowed was true; now that DAC has a real bound check, that combination is reachable and must not fall through into iommu_arena_alloc() with a NULL arena. Mirrors the DMA_MAPPING_ERROR return pci_map_single_1() already gives for the same situation. DAC capability itself is unchanged: pci_dac_dma_supported() still determines whether a device's DMA mask can address the DAC bit at all (a capability question). bus_dma_limit is enforced separately, at each mapping site, against the resulting address. dev->bus_dma_limit is a numeric upper bound on the end address of a transfer (see dma_capable() in include/linux/dma-direct.h), not another bitmask to AND against. bus_dma_limit defaults to 0 and min_not_zero() ignores a zero operand, so all of this is a no-op until something actually sets bus_dma_limit on a device - no behaviour change by itself. This is infrastructure for a following patch that uses bus_dma_limit to work around a Tsunami/Typhoon-specific DAC issue; kept separate since it's a generic, self-contained change with no policy attached. Suggested-by: Maciej Rozycki Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/pci_iommu.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 955b6ca61627..6191dcd560bd 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -228,7 +228,8 @@ pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size, int dac_allowed) { struct pci_controller *hose = pdev ? pdev->sysdata : pci_isa_hose; - dma_addr_t max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK; + dma_addr_t max_dma = pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; unsigned long offset = offset_in_page(paddr); struct pci_iommu_arena *arena; long npages, dma_ofs, i; @@ -250,7 +251,8 @@ pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size, #endif /* Next, use DAC if selected earlier. */ - if (dac_allowed) { + if (dac_allowed + && paddr + alpha_mv.pci_dac_offset + size - 1 <= max_dma) { ret = paddr + alpha_mv.pci_dac_offset; DBGA2("pci_map_single: [%pa,%zx] -> DAC %llx from %ps\n", @@ -549,7 +551,8 @@ sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist *end, #endif /* If physically contiguous and DAC is available, use it. */ - if (leader->dma_address == 0 && dac_allowed) { + if (leader->dma_address == 0 && dac_allowed + && paddr + alpha_mv.pci_dac_offset + size - 1 <= max_dma) { out->dma_address = paddr + alpha_mv.pci_dac_offset; out->dma_length = size; @@ -559,6 +562,10 @@ sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist *end, return 0; } + /* No IOMMU and direct/DAC didn't fit: nothing left to try. */ + if (!arena) + return -1; + /* Otherwise, we'll use the iommu to make the pages virtually contiguous. */ @@ -654,12 +661,14 @@ static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg, /* Second, figure out where we're going to map things. */ if (alpha_mv.mv_pci_tbi) { hose = pdev ? pdev->sysdata : pci_isa_hose; - max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK; + max_dma = pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; arena = hose->sg_pci; if (!arena || arena->dma_base + arena->size - 1 > max_dma) arena = hose->sg_isa; } else { - max_dma = -1; + max_dma = pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : -1; arena = NULL; hose = NULL; } @@ -719,7 +728,8 @@ static void alpha_pci_unmap_sg(struct device *dev, struct scatterlist *sg, return; hose = pdev ? pdev->sysdata : pci_isa_hose; - max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK; + max_dma = pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; arena = hose->sg_pci; if (!arena || arena->dma_base + arena->size - 1 > max_dma) arena = hose->sg_isa; -- 2.53.0