From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 6BFF83C3BFA for ; Thu, 2 Apr 2026 11:26:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775129171; cv=none; b=bNx185r22egVx4/HUurWuUWZ0ruZw++N1bUg+SYAqNEEhGCyH4PVdtV735RI4wzT+1zBOwrqAOOlBn8MZwX2ujnfS0BuCOL6buN+5nRXdUCtaltbJaBqQmzGtt323QD+Bt5thSR42dhc1ezl7YlsBJAnE4X/PU+5bJCvHw7uuHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775129171; c=relaxed/simple; bh=M6U4j/NLiQ+/4aHjkSTAmvKfIhe8Sr7hjNTZaZUG7ts=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LXasep3wq7I5QIF242buR2zcxJ8aUb4wNttFx2GjI6iTvhDCg1C9pef86dNI0LjewbJFO71Vwlq8spP61lf5o8wdhY/SISAm09jfBm3fF3Su06qeGgv4FWMAlk9yzAZLLK5MB3qNoxhQOppJQsiInc35AisfpXnOcvORSDKRYoc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=qxg8ONZ/; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="qxg8ONZ/" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4853e1ce427so8669785e9.3 for ; Thu, 02 Apr 2026 04:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1775129159; x=1775733959; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=r5JQGdVakt/jSwsp5LQgcZLl+3LElhn2BfzsSs+MpKc=; b=qxg8ONZ/iN0/apf/OpTmRm8qxs6YGJVBmFU98HzmaDlpfox/AQB4AP4fIkQCQi/bkZ kIUPq+cL4QQ293WvW9bPkK4ndKLOxCiHZIvi7i/Uu3J6jf9VJ0mirecvy4Jz3f3JUn7I sbiuE8j92dzdUM2PuwTRQE+hpsf2OsZ9Unsk5dWMIfXKz5vKAiwUz3Ufb4ee+xSMv+Fr OGfvV0EvHFTcbpSXSlUa9zl9wwLyS//alDmbfxHWSk9mqpSadH1o35fDmoi/d3/2LgS8 04XIchzP26UH4Y0ikNaN1tvJgIGfYWX81ZJXKhcoShAekciCUZ96aFXPIASpOc+O71TM UYYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775129159; x=1775733959; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r5JQGdVakt/jSwsp5LQgcZLl+3LElhn2BfzsSs+MpKc=; b=maUh/oh2Q8Nj0dUJeoLHHHUnnz2PzQPbPpLD2l8Orttl3PywCG+jSjxHgw79kqhg5Y 0cRdqsr2GNc6d7sFZc44DC/zj637x2eEu8BBHth3hramaklNgoWP/CznDAPojGYDOZjk OF3tcKLnuyE5xA42ZIE8XW47Z/6c2FqCcJGTmYob3peOWqMkaJjzlDVZAvyK7X88A6Y7 KRGVAABI7cHcKSw/1Ph4Fctk+36K5S0KmkK/0nC7sBY56Kboa9SvEPT4Q8xMllvc86PY s4qWrNV0hmQRzuitKpCu4LdQ8ppqxx5ewkA9xPAw/7g2E+EEjNpyvLgZXC48mgLk+U15 Vtpg== X-Forwarded-Encrypted: i=1; AJvYcCXAACg4dG/FouLMGPVlUeZ3OTWDAUJl1Aie8emXfZCtmg4s3pYFC/j9wV8RrcmIXl3WKNU7bi+Z8Uw2H3k=@vger.kernel.org X-Gm-Message-State: AOJu0YxYlA9xMHxKLPaKbuMtZtG1jBzaxZg7hEHsE6sHCSgzJRK2r23j co4rANOthaHbnEHo7gaNejJrfAhg+MjJpc5psMG04RpbOrmNU5yc1McaeulrbZlq8GQ= X-Gm-Gg: ATEYQzwJkUimr1Hja7Af879j9UHnCganrHMjVRYx4hfJ+4AOktqC4Q68vM8jRwEU33x pu5bRXTGDvuptcAVZbJF27bKs9oVqUUyVKInzCBiODpCxo8CFoevG72CY2YfZ7zVxOqswiZQIua C5rBJRPXQ/GLkQV5RH9SlHVttSspDBWdKdOgNlz7f9GR8jAa3lvC6QggGWN/mej/YoQ718pkUAO wSJZW8Lz/Bp3H+d7+cJYdH6lQTO68Vj26e2l0bcwmoe5mjvh8jeJjTQ1Hqn23hM7zAcKrjQhrAZ 3ETpB6ihMqSJRnBJIrzgxQWYyTHys0hMfgwXXDmMBokXqSKHXTvyBLmKkgrZnAoxuwp9mwWte6e oGYvHHrR0mIGqAuCknzvTL6UFLgufQ9EfZXKusdNYRIoqTbsmB94FRCueB52g/U/vVoY9fEG6sa aWGkAq+0EkT7hDofHf03qKEohFhIQ4oc0alI6Wf7riog== X-Received: by 2002:a05:600c:4744:b0:485:30d4:6b9e with SMTP id 5b1f17b1804b1-48883591f01mr121033965e9.21.1775129158565; Thu, 02 Apr 2026 04:25:58 -0700 (PDT) Received: from [10.11.12.108] ([79.115.63.48]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887ad1cd86sm65951315e9.5.2026.04.02.04.25.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2026 04:25:58 -0700 (PDT) Message-ID: <9892a17b-022e-41df-af1c-a2d684aa8db1@linaro.org> Date: Thu, 2 Apr 2026 14:25:54 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] iommu: Fix bypass of IOMMU readiness check for multi-IOMMU devices To: Jason Gunthorpe Cc: Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , "Rob Herring (Arm)" , Joerg Roedel , Bjorn Helgaas , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, peter.griffin@linaro.org, andre.draszik@linaro.org, willmcvicker@google.com, jyescas@google.com, kernel-team@android.com, stable@vger.kernel.org References: <20260323-iommu-ready-check-v1-1-5f6fef8f9f59@linaro.org> <20260323135414.GA8437@ziepe.ca> <1062b66d-e4d0-4eee-8fc2-dbb65491a01b@linaro.org> <20260323173138.GB8437@ziepe.ca> Content-Language: en-US From: Tudor Ambarus In-Reply-To: <20260323173138.GB8437@ziepe.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, Jason, On 3/23/26 7:31 PM, Jason Gunthorpe wrote: > On Mon, Mar 23, 2026 at 06:46:39PM +0200, Tudor Ambarus wrote: > >> Downstream we have a display controller that's using: >> iommus = <&sysmmu_19840000>, <&sysmmu_19c40000>; >> >> These are 2 distinct platform devices, they probe independently, they >> each call iommu_device_register() independently. > > Sure, I guessed that is what you ment.. > > Do you have an example of this in an upstream DTS file? Yes, Exynos multimedia blocks use this upstream For example, in arch/arm64/boot/dts/exynos/exynos5433.dtsi, the `decon` and `decon_tv` nodes route through multiple sysmmus: iommus = <&sysmmu_decon0x>, <&sysmmu_decon1x>; Looking at the upstream exynos-iommu.c driver, it doesn't return -EPROBE_DEFER if all the instances listed in iommus doesn't exist. It seems it survives the race though, but only because of the core_initcall ordering. In downstream the IOMMU is forced to be a module which exposes this gap. > >> If I understood you correctly, the downstream driver shall model its >> architecture and call iommu_device_register() only once after both >> devices are configured. > > No.. I'm not being so perscriptive, I'm just saying that once > iommu->ops->probe_device() returns then the device is fully setup and > dev->iommu will operate all of the iommus described in iommus=<..> > > probe_device() cannot return some half setup device with only some of > the iommu instances working. > > We don't have any core idea of a half setup result from > probe_device() today. > >> If the core's intent is to strictly enforce a single IOMMU instance, >> shouldn't iommu_fwspec_init() be checking >> fwspec->iommu_fwnode == iommu_fwnode >> instead of matching the ops? Because the core currently matches on >> ops, it permits aggregating multiple physical instances with the >> same ops into one fwspec. > > The driver is responsible to handle this, not the core. It has to hide > this mess under its covers, not rely on multiple calls to of_xlate or > however it has been hacked up. > > Probably it means something like of_xlate/probe_device has to > EPROBE_DEFER if all the instances listed in iommus don't exist. > I can probably track whether all instances are ready, and defer if any is not ready, but then I'll force the iommu clients to use the sketchy replay path, which seems like a bad idea, according to Robin's feedback. I haven't seen functional problems with the races, just the "something fishy" dev_WARN. Maybe we shall downgrade that to dev_info. Thanks! ta