From nobody Mon Sep 28 08:01:28 2026 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: quoted-printable Content-Type: text/plain; charset="utf-8" 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 <=3D 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 =3D -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 padd= r, size_t size, int dac_allowed) { struct pci_controller *hose =3D pdev ? pdev->sysdata : pci_isa_hose; - dma_addr_t max_dma =3D pdev ? pdev->dma_mask : ISA_DMA_MASK; + dma_addr_t max_dma =3D pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; unsigned long offset =3D 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 padd= r, size_t size, #endif =20 /* Next, use DAC if selected earlier. */ - if (dac_allowed) { + if (dac_allowed + && paddr + alpha_mv.pci_dac_offset + size - 1 <=3D max_dma) { ret =3D paddr + alpha_mv.pci_dac_offset; =20 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 =20 /* If physically contiguous and DAC is available, use it. */ - if (leader->dma_address =3D=3D 0 && dac_allowed) { + if (leader->dma_address =3D=3D 0 && dac_allowed + && paddr + alpha_mv.pci_dac_offset + size - 1 <=3D max_dma) { out->dma_address =3D paddr + alpha_mv.pci_dac_offset; out->dma_length =3D size; =20 @@ -559,6 +562,10 @@ sg_fill(struct device *dev, struct scatterlist *leader= , struct scatterlist *end, return 0; } =20 + /* 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. */ =20 @@ -654,12 +661,14 @@ static int alpha_pci_map_sg(struct device *dev, struc= t scatterlist *sg, /* Second, figure out where we're going to map things. */ if (alpha_mv.mv_pci_tbi) { hose =3D pdev ? pdev->sysdata : pci_isa_hose; - max_dma =3D pdev ? pdev->dma_mask : ISA_DMA_MASK; + max_dma =3D pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; arena =3D hose->sg_pci; if (!arena || arena->dma_base + arena->size - 1 > max_dma) arena =3D hose->sg_isa; } else { - max_dma =3D -1; + max_dma =3D pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : -1; arena =3D NULL; hose =3D NULL; } @@ -719,7 +728,8 @@ static void alpha_pci_unmap_sg(struct device *dev, stru= ct scatterlist *sg, return; =20 hose =3D pdev ? pdev->sysdata : pci_isa_hose; - max_dma =3D pdev ? pdev->dma_mask : ISA_DMA_MASK; + max_dma =3D pdev ? min_not_zero(pdev->dma_mask, + pdev->dev.bus_dma_limit) : ISA_DMA_MASK; arena =3D hose->sg_pci; if (!arena || arena->dma_base + arena->size - 1 > max_dma) arena =3D hose->sg_isa; --=20 2.53.0 From nobody Mon Sep 28 08:01:28 2026 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 6AA1B377EA7 for ; Mon, 24 Aug 2026 18:11:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787595117; cv=none; b=jgljSv2QkOHbmzIUtnxFaGvnTX6G+gEkpNBIWhHHrfDjzX1/QblvALFy3qzyAbnMXHEYD/Hs4z/06fN6U5gcK7Ve2sJW1SsJqJe9Xo0jo3V/yAFUZR7LzkueGLvHDYLk1DlRZ/QYxTHJ4UKQEk/QFmTsyhhEY9+Jzpla/9JTBxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787595117; c=relaxed/simple; bh=DoyynfnFNtu8deR4YMJFA+pR5wIO3iFw49c+1eis2pM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a68M86/ZATNQYpI11BDBn2ZA+QYA5xL8zschTqihT4GR/Vu2TnogK5hNmz28nFg7TY+86UK/jxAZCNvKVTZGQYWh2wzvL6gYq3cT1Z9sL68qz+rPW02wn9KGZUAhWZKUYPR43tOhhwYhCwVWYgvBbD7sZnykJ2wzvs67i/bsge8= 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=PaZNEkji; arc=none smtp.client-ip=209.85.208.46 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="PaZNEkji" Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-6a0c8283146so6528943a12.0 for ; Mon, 24 Aug 2026 11:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787595115; x=1788199915; 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=Zj2q3arXj3Q/m3Lr27G5YOHVKwirt8ukHHM6JzuqaPg=; b=PaZNEkjiXneWo/tlnW3Tx/fpAWpG8Qn1MlbYgQ+ReiP36lNqNJlaw5+YGHc90Acuuh I0EKaxUXyMlil0eglyAJxtle3n9TMzeBK46YXPCERce+RBmttIEriyX1/0bWBYS5V/yH jT17W0Xay+gYkwhO+jRfs0Pe21XPv6/kHreDefSKZy6B48jTXwaRYAdyH9A6+lrjp4Dq XX789uZQ26SVOgmnGtPAmWTtcXJKj58UyLneQr45M3qrIzwB4pReS34YZ0MUtALiMfoi XDAjW1Jl+RU+ExL4gwSroPo7xnnnW5VEF2w0Z+JjvCrl7haa6F98+VGPOuJTfSmvcY+i fIug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787595115; x=1788199915; 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=Zj2q3arXj3Q/m3Lr27G5YOHVKwirt8ukHHM6JzuqaPg=; b=AKaQeeuhwqTlaXfbAznv6Gf8g7720wnbYPgjpwj4Q+mEJiXn+MhpTtHdN9zkQ3zUsn 6KUXAAHH1HsJaWN3HbOlZfQscwEry6F5lqchLlPqUu3Rkg5HZU3EDPIsdIP09FB3iEt8 ZaaiKT20iw60nbFHKazvIIpp5eKc1QpG5VGiJc96gVMkCmC71/SwEU2EgnDrVQcoSW11 YHrpUCVHYnzEZILrJ8+kUXb69cyWMCPABWNeEB2+19rq59bR7JwGnS2A6wYVW+J6xZPG GS5vrXmon7xLeMBJpaI+5Yh95SIatUEUbfrzfcYosbRbalqJBwLTaiNe/meHrC03FseN YHLA== X-Forwarded-Encrypted: i=1; AHgh+Rq4JXyqUoFz/9VzxCVuFUlqFVOhmcD0DUGhjsoO/JbThW/MrYSzSLuF4mGOlesMqQtGtkyB1NsX+ZQ8cbg=@vger.kernel.org X-Gm-Message-State: AFuF++mFGbEuS1Ulab9H/qHzqQegXVIJsEdfnmFu1VkDcMYZavqiGf+S a53vZTH3xSG5BXKRakyyDDww1yLGbRtjscWSMvXBu2ljHV3w6w7dQZKW X-Gm-Gg: AR+sD13pZQkm8myM3c2vbGzH84HMlPBFWegAT/zpAYAIQimCU+9M1xEbUHbBZfFVaDo tP8JjnatteunfVFf2CFGAN3JVgYISjWqa6w8cBx+7WsAKW5OltpR773ep+SWqK0Gxz0xgHhPPYZ gJT1YboWo/HCkFWtZRBor5+Me1bq2+rsJJN8J63aGRMrGiaFgw0H/N51IaavOcc2WEfzws8nzLQ IxQDfz+l+j0HHLcazf4dskYb9tX5MLGyLSAXn2cbVdGbXqX2Kv8IpT9VHc0LHDpNs1mMKLTufaB pD+NJJ0OiMBjnlRoHPcUzm8Tt1YV7hapKEe8N84VqFRCXQvHkt6eA6JSHXIR+ZLcbvgfJbtvxuF tNfKwFCwLjCZfnhyaVj8V/XOIgLhoV0c90pAuge9iqsnUS6Gj797mraUeOIJ0gJY4vQ+5TXsWrs jDeUXV6cr9TqWXy02Uw4/4omqRHpnzBtwe3WElCImmDb2vciYQVcH+LbVtc5rsV9RPSF4D5yD14 Yo9ShGi2QV+pYiyxa9Qm4iSXUIQWu8= X-Received: by 2002:a05:6402:2187:b0:6a3:905b:3c40 with SMTP id 4fb4d7f45d1cf-6a42f1d0649mr31076425a12.8.1787595114678; Mon, 24 Aug 2026 11:11:54 -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.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 11:11:54 -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 2/2] alpha: disable DAC for 32-bit PCI cards on Tsunami/Typhoon Date: Mon, 24 Aug 2026 19:36:54 +0200 Message-ID: <20260824181126.3559638-3-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: quoted-printable Content-Type: text/plain; charset="utf-8" The Tsunami/Typhoon Pchip's DAC ("monster window") path corrupts data when used by 32-bit PCI cards using DAC addresses above 4 GiB, even on cards whose DAC support is otherwise solid: the same cards work correctly with DAC on Rawhide (MCPCIA) systems, and native 64-bit PCI cards are unaffected on Tsunami/Typhoon itself. Corruption shows up as 64-byte chunks (one 21264 cache block) of unrelated data - typically identifiable content belonging to other processes' concurrent DMA - substituted into the transfer; the rate varies from none to several kilobytes per run and has not been tied to any particular alignment. Work around this by capping affected devices to 32-bit DMA, which routes them through the existing scatter-gather window instead of DAC. Conventional PCI provides no status bit to distinguish a 32-bit from a 64-bit option card, so use the presence of a 64-bit memory BAR as a practical proxy. This covers every affected card seen so far, but is a proxy rather than a direct test: it will also needlessly restrict a handful of 64-bit cards that only expose 32-bit BARs (e.g. QLogic ISP1080, ISP10160). These controllers are not known to be supported by SRM firmware and are therefore uncommon on Alpha systems, so the trade-off is accepted. The only driver currently known to hit this is qla1280 with an ISP1040 card and a 64-bit DMA mask, which is a common and SRM-supported configuration on Alpha. Suggested-by: Maciej Rozycki Signed-off-by: Magnus Lindholm --- arch/alpha/kernel/pci.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c index 11df411b1d18..7dbf380acd93 100644 --- a/arch/alpha/kernel/pci.c +++ b/arch/alpha/kernel/pci.c @@ -23,6 +23,8 @@ #include #include #include +#include +#include #include =20 #include "proto.h" @@ -117,6 +119,26 @@ static void pcibios_fixup_final(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, pcibios_fixup_final); =20 +/* + * Tsunami/Typhoon's DAC "monster window" corrupts data on 32-bit PCI + * cards; cap them to 32-bit DMA by proxy of having no 64-bit BAR. + */ +static void tsunami_dac_quirk(struct pci_dev *pdev) +{ + int i; + + if (hwrpb->sys_type !=3D ST_DEC_TSUNAMI) + return; + + for (i =3D 0; i <=3D PCI_STD_RESOURCE_END; i++) + if (pci_resource_flags(pdev, i) & IORESOURCE_MEM_64) + return; + + pdev->dev.bus_dma_limit =3D DMA_BIT_MASK(32); + dev_dbg(&pdev->dev, "disabling DAC for device\n"); +} +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tsunami_dac_quirk); + /* Just declaring that the power-of-ten prefixes are actually the power-of-two ones doesn't make it true :) */ #define KB 1024 --=20 2.53.0