From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f52.google.com (mail-yx1-f52.google.com [74.125.224.52]) (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 E90B339182F for ; Mon, 23 Mar 2026 17:31:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774287104; cv=none; b=OjThJ7fRJ8U3PDMP64BtXEK6yYiA4CkzK/loAJUbY+rMP6jwvJiscHcMIupAjo6Jqhz1YYQR/q5wzWS6oNH0XUVjVtM7zuyAJZUIVDhMscIizqfS+kW4rAd/GFhvilVOOlOB+frTr8vE0W7tP307TcfxiULV/ZnPKQGdQgvREYI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774287104; c=relaxed/simple; bh=mBhx/iGMR6MnTH62/x8K0OvjgYxObT0PTNXZZqCOHkA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q/pH2uY2nOVgpZm2ze/uRNGV72TOpktaz6QTOpopfvJGORvn9UoxbWHEusuCwNN6eX4ONspElSoLVtNV/0F1gzoc5qHv1CYzfvwIDlMY8Aco+ty0wBlF4bdQwubMxUa5clumKZf+N/Ty6fr6AYy/7/iYJ4q7Xbn7aEPvOFmuJH8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=jXjZaRId; arc=none smtp.client-ip=74.125.224.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="jXjZaRId" Received: by mail-yx1-f52.google.com with SMTP id 956f58d0204a3-64acd19e1dfso3699546d50.0 for ; Mon, 23 Mar 2026 10:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1774287102; x=1774891902; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=L7FawmBPSYeihgLrf84TswLXrZodyF3L+TdguCBeUDA=; b=jXjZaRIdu22bGrftrd+cAzDRaHm3ZYhEcNyTmCeQbkAFpqxBn89Tc2Mvh5TScyrQnx g/wOwYTP3gy2UMR09ci8EtsdwNPK8qVtQ73Er/IGi/UVkCQzCavdEhiTnIzKuYo6ARyx 88WI6ftq5ZlrljHVPXdJ3PTUWAqlBqxAR51/QCFFjBGs99KUKxzV+tt/tnp2xDMrMcd+ EFn9tGStZztHiMAiqbzabwAJb+uignTqRxmuFRq3tPX4pbpjjAftuKeo3x1Jd4mb6mea /IhcTsD7oKmE/tkpN6mkRTtW7yMkdbjhbgFtkRzpT76hKFLvjPdJ1cguLtyVzQThccoG WRLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774287102; x=1774891902; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L7FawmBPSYeihgLrf84TswLXrZodyF3L+TdguCBeUDA=; b=WziQnYHEow0EplEcp1n+qz+r6GbwhteC+ddwA/L8X7gqsXFbdo2JNlvNYaI24kU8KX ogIQAZQAOlHXWTfTI6QWXgv8hR3k4ZJTu3Qar+dbQoKlC9xvCKDa7ksXcP3hnEfW8J3s 7nEw22iIA1sCGeerwUZ2yaX2OP/1aTfykrmYXdxAZMRBDNKAcDi45cYTfYamP7hRfOEn iIvsfMvcczhyuqE1pb1DgVEKUAWsXEmZTRWR8ypSkLBdfKMbr27ix+0lzfI9y52eNkRT TkmXXNQ8w1XkpnzBzI7zFCqERc/HhKT0ue86604RYydEqvXClMLCBBzRHJRAGDkrtb4F htXw== X-Forwarded-Encrypted: i=1; AJvYcCUZB52WCRJFcnhk2EDAC8IolZS7n09YTeH0hEm1y5HZ2Zy+qyBCFUyGU53vQZkYAFPvowxn6cjjKLCzFAQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxvhIxniQlX6/3teL2/1t2wg9ZjgBOdv9v6oe8xov02YrwhFkt8 hx/JVNSG+JzYEjU2ZGbvI1E+E+BI+tSLGeqJTsBiwEwENWle0oyuDuc1iPWOBqisMZY= X-Gm-Gg: ATEYQzyNExT+gc0M1FH3h6kYdnOM4xq1T0ex/oDadK8EBUgKvp0YJzw8QJAA+Ru8RTj fwoq604dTGmMsW0F5qS6NO0bPVzTEIFlr0Zwc01fEcRLloKUnODAbi+69Jcv21OdgnsDZBP0YlC 18NzT0HnxXM5vGFiieT0bW4y8b2nheNOumTXL+FtyMeEmbDLNWAVC7C2vtMcPfPgCi4CucXfk4u BRlykeUVrOEP3eDrxgKuWbKg+MbPSJFYVUA3CKVxSJALrihIyUSlQ/2Yv1ZbZfRMJo1dipk2JP9 CNSDwjjconqcjHdRHb8QvMvK+j8Qgk1OcMTZ7iceiu8/enJNvFvmtA2RGrnlnuKqhrCxJ4fUe2P btD/XL2UDAoluWiVGp9HURYVU5h6qAHK4fb74uChpXpilkoSESn9Y5NuTFxy2lIbzTxcSdRiQru nnHgMYnOPa4iy8QqGbrhq+KknCvjpIGmoC0DP4q/WRODpfa60QB85SnPR2dzz3Cdd8wfeafg== X-Received: by 2002:a53:eccf:0:b0:64c:9a6d:66bd with SMTP id 956f58d0204a3-64eaa6a2105mr10583694d50.8.1774287100249; Mon, 23 Mar 2026 10:31:40 -0700 (PDT) Received: from ziepe.ca (mctnnbsa70w-159-2-73-22.dhcp-dynamic.fibreop.nb.bellaliant.net. [159.2.73.22]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50b36d071aasm88833571cf.11.2026.03.23.10.31.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 10:31:39 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1w4j7q-000000006of-48OA; Mon, 23 Mar 2026 14:31:38 -0300 Date: Mon, 23 Mar 2026 14:31:38 -0300 From: Jason Gunthorpe To: Tudor Ambarus 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 Subject: Re: [PATCH] iommu: Fix bypass of IOMMU readiness check for multi-IOMMU devices Message-ID: <20260323173138.GB8437@ziepe.ca> References: <20260323-iommu-ready-check-v1-1-5f6fef8f9f59@linaro.org> <20260323135414.GA8437@ziepe.ca> <1062b66d-e4d0-4eee-8fc2-dbb65491a01b@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1062b66d-e4d0-4eee-8fc2-dbb65491a01b@linaro.org> 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? > 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. Jason