From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 899172C0F96 for ; Thu, 6 Nov 2025 17:16:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762449419; cv=none; b=NgTPvCZeCOJY53ExfBN6JPjW7T/tZhJIVeMPX17FLIpoHqZZYMmX+WD+xLRwP8Tw5qMbuuITQpu3CJ1bfG0yey6WdAYPNMx8cXjHbw0HtdGWE6HoBTwQ9mcSgQ9GEYinr1OSbxcZvv9rLwVi9n2YrU+TDriwpmsjNt2RPU0flWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762449419; c=relaxed/simple; bh=dIwybaZojCu29+P9gEfB8CIvmj6Bl08p1VgiPhwpKTo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dOSl3c466tLcJKZt4jX/f3LzjRieS/DtQubOfNB4FzpbheK6p1yWMr6iS0Y7WA2S6+6bVh1xZxgtpr6cDjGT0EQp2IQ9CJdJDIk/qsRyq9ui/TpjlrkZgADeYSwZk6lBjaUMwBzw7BrQnFg75O2C9JICZ2iUu/+kz09DYE0WO+8= 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=fEmZskmt; arc=none smtp.client-ip=209.85.160.178 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="fEmZskmt" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4e8a25d96ecso9817671cf.0 for ; Thu, 06 Nov 2025 09:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1762449416; x=1763054216; darn=lists.linux.dev; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=XyqXd6ge5y2aj27CRXRh3J8Q1q4rd+TcymckOxNEG8A=; b=fEmZskmtaptejch4msph1FdQkdP/R8M9OyiBrYBY5+0s8wjOoLMT1qg7wQk42FNbP0 oAzW0rNsuy8yowrg1wZh1EAo4zNOSxhUviusHmHfQhE+xMRH6DC5a018eWDEtni+32kU zoSnaSO1Kkee9suZwzfGum/mKFaQXD3PkFJfI5pmkOm/uyD0DOjJmQjGJlM3Dn0PVP7g H217JKTo+71bC5hbjuzh+nFwDxePqy0XjfQZ5mmtkItpvv/GEeYCM0d7qjNXo0od1tIu FeZiiHPeghao2aQ6b+78dGAJO3UDJ4NSFsDxJ3nEalLe+2JBXZqYpE5fFMSAgqkkjsnl qLRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762449416; x=1763054216; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XyqXd6ge5y2aj27CRXRh3J8Q1q4rd+TcymckOxNEG8A=; b=nRrHbi2TJdVGAzjpcvgrxXwWIgSAnLJ+nYQd05aeB1124ar3xHUu5Kh/F+DrFuZKLG eCiqdWrsNe43OC7+sRdrGW1x99vFVYd0I9cS/fds0C0JozYN5cqZ+OZU2CAnE8E6nGBb vwCIioICaSBUti4cgkmknwsU3JP2MmlGjsciVAJeKJxCeKw5F8TdAta+sAWZ4o3NnlxR tm037qTbscM9AYXlS0w8uCHpygw51w5HL3dzxYh6gmFeuFn2o8NuA50oLyv3oiOWpD+p a7xb5ivtdQeKlqY89DNVPWoq/TA0nPggZSDEaeo0CdTuqw+YIcyhtG28oXZTAun4HajV zv0w== X-Forwarded-Encrypted: i=1; AJvYcCVQjs07UMyJP0Xv1AW/ZQYGuXKrSJRc/QO+vx5KNKIF8915SUJsB6PkvPp+xZBOudvVRqP/tQ==@lists.linux.dev X-Gm-Message-State: AOJu0YxgPu6dGUBnrvAUVAvRKH7qzfWUlDdGkVvwP4P06GA6P2Jc3eLG I51jVRs/vjFnjpkqbW6ghl+Q4nyEDRxkc2pe/6QcvXwBPiTK2VvHKodYAT9Sr6HR52c= X-Gm-Gg: ASbGncuzFiQW0nXES/yIHfM+3rh7DdnbPPcd1v6/t3dO4uZdfKHXhuH/zlCJTZDWyE2 /CTp6ZxNOMP+t4U50ijsiEEiLZKNYevfFeOJcKaWR3PU43qEqbE1NUwcz5muGCL+YWlyFpasGVd YHVSKfm0H8ZTgzYBLZ/PrsAws+ao4KqoGMBynielzGDkqauE8qWzNeHEUU6hw9OOb7nk8mwyByF QjW3Rhw7KFwqE88JvDRXlvsREf97xsaYIcRbBIGrk27L5tB2lZwqF+24uVWCT9QUoJZmHXJtAzq nH1rDmrOYbXi7LU5lJhjnzzq+w/jkJWbYJWrqeohANA7PIoJa2E8JJkmzK4zFhhE7SE5wefN4Hu sVvygAR6ipv/fWwpPGSv67klaoxIGhdlmMMXRgH+SRe5hTg336cuOe+TGxOOVwJpujBbWhMCN1w lWDD9f9jz+AGU5BQfMjshUiRK1MUO8yAiPy5KODBO++KFahg== X-Google-Smtp-Source: AGHT+IGm7rjI4btGT0uAp5U2+RTOpSSDx/JneJwxU99rel9EmV7Mer/iD0OJK3RWNsxIkY3fdHP+mA== X-Received: by 2002:a05:622a:410d:b0:4e8:ac66:ee44 with SMTP id d75a77b69052e-4ed725e06eemr111576881cf.39.1762449415840; Thu, 06 Nov 2025 09:16:55 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-120-4.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.120.4]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ed813b7ce2sm21908131cf.24.2025.11.06.09.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Nov 2025 09:16:55 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vH3bS-00000007OJk-2iYD; Thu, 06 Nov 2025 13:16:54 -0400 Date: Thu, 6 Nov 2025 13:16:54 -0400 From: Jason Gunthorpe To: Mostafa Saleh Cc: Will Deacon , linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, robin.murphy@arm.com, jean-philippe@linaro.org, qperret@google.com, tabba@google.com, mark.rutland@arm.com, praan@google.com Subject: Re: [PATCH v4 15/28] iommu/arm-smmu-v3: Load the driver later in KVM mode Message-ID: <20251106171654.GV1204670@ziepe.ca> References: <20250923173806.GF2547959@ziepe.ca> <20251002151308.GG3195829@ziepe.ca> <20251105171208.GN1204670@ziepe.ca> <20251106132331.GU1204670@ziepe.ca> Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Nov 06, 2025 at 04:54:38PM +0000, Mostafa Saleh wrote: > Maybe I am misunderstanding this, but that looks really intrusive to me, > at the moment arm-smmuv-3.c is a platform driver, and rely on the > platform bus to understand the device (platform_get_resource...) > > You are suggesting to change that so it can also bind to AUX devices, then > change the “arm_smmu_device_probe” function to understand that and possibly > parse info from the parent device? Yes, it is probably only a couple lines I think. You still have a platform device, it just comes from a different spot. I didn't it audit it closely, but basically it starts like this: -static int arm_smmu_device_probe(struct platform_device *pdev) +/* + * dev is the device that the driver is bound to + * pdev is the device that has the physical resources describing the smmu + */ +static int arm_smmu_device_probe_impl(struct device *dev, + struct platform_device *pdev) { int irq, ret; struct resource *res; resource_size_t ioaddr; struct arm_smmu_device *smmu; - struct device *dev = &pdev->dev; smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL); if (!smmu) Probably needs some adjustments to switch places between pdev/dev, but the ones I looked at were all OK already.. In the aux case dev is the aux dev, otherwise dev and pdev are the same thing. devm related stuff has to dev. > One of the main benefits from choosing trap and emulate was that it > looks transparent from the kernel of point view, so doing such radical > changes to adapt to KVM doesn't look right to me, I think the driver > should remain as is (a platform driver that thinks it's directly > talking to the HW). I'm not so fixed on this idea, this kvm stuff makes enough meaningful changes I don't think we need to sweep it all under the rug completely fully transparently. If you need a couple of edits to the probe function that's fine in my book. Jason