From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EBBC2472BD; Thu, 2 Oct 2025 12:18:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759407523; cv=none; b=pfENAwTRnoGuW9Nm196QVQPd+GKMLfc7re8fMqyAs6uNiydlYJTQo4YHVJWdZCxdPr8LcxlUFO+NPqULMjO6OGGSW1Q3ZNZE+MNmSvhlrbDnOUCOfvaLf+FGpMFerZhjIb/9H6v/T44VUGxx3vh1boMds3LO6ZWCyn4Xn9K81zI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759407523; c=relaxed/simple; bh=XJh2rU3g6FXXRr4HSBSk9BT1NPgHOKWJMap6jFw2cfg=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=MKDv0YsW00JpzTGhWyr5czbwYZOjpNbRjt2XDTIk+aSAr+nWnJ0xB4wk01Yo/offXWWJu4aYLNfD4lsFWNzSU3AGLuGlEnIQP/6KjjIBewr3WEelrNuWMEKpieOpMZXTPRQrwjrUKP2XCV3QpgtcVeLwLKJqmtycXekxB5lGRsI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Itkbsf7K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Itkbsf7K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9B33C4CEF4; Thu, 2 Oct 2025 12:18:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759407522; bh=XJh2rU3g6FXXRr4HSBSk9BT1NPgHOKWJMap6jFw2cfg=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=Itkbsf7K6rt0J5zJFgF2UWghEIS0HfpbGyuQ1ojxLJcd8r+glln6f3tNWRgQNH9Iu Fb0f2Uy8sXoj6ke0Pi52KQsLjnpRlVcFcAeGMfiP2TqxuDvK8rq/243Csf5o/c9A7I Xd99xQIkKU1pN24b/Awhcjpjpdg/rXg9j6pdv1y+5evbPfL+U07Sas6zMq5HfOFpE8 PRDexDCSSFaW980uSnl5JKkjuBV1DDd4/j2BefmELCFAr/1xIrZkmkQOxpNHH93dYS KVIm9J47v/2XiWmweZPaNtcIH9DfZuks4kFpN+EzPXElqJYsohsCakGqqqXkYtNtBq gXPjP5WhMTT7w== Precedence: bulk X-Mailing-List: linux-pci@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 Date: Thu, 02 Oct 2025 14:18:36 +0200 Message-Id: Subject: Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs Cc: "John Hubbard" , "Alexandre Courbot" , "Joel Fernandes" , "Timur Tabi" , "Alistair Popple" , "Zhi Wang" , "Surath Mitra" , "David Airlie" , "Simona Vetter" , "Alex Williamson" , "Bjorn Helgaas" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , , "LKML" To: "Jason Gunthorpe" From: "Danilo Krummrich" References: <20251002020010.315944-1-jhubbard@nvidia.com> <20251002020010.315944-2-jhubbard@nvidia.com> <20251002121110.GE3195801@nvidia.com> In-Reply-To: <20251002121110.GE3195801@nvidia.com> On Thu Oct 2, 2025 at 2:11 PM CEST, Jason Gunthorpe wrote: > On Wed, Oct 01, 2025 at 07:00:09PM -0700, John Hubbard wrote: >> Add a "supports_vf" flag to struct pci_driver to let drivers declare >> Virtual Function (VF) support. If a driver does not support VFs, then >> the PCI driver core will not probe() any VFs for that driver's devices. >>=20 >> On the Rust side, add a const "SUPPORTS_VF" Driver trait, defaulting to >> false: drivers must explicitly opt into VF support. > > As I said in the other thread - please no. > > Linux drivers are expected to run on their VFs. The consequence would be that drivers for HW that can export VFs would need= to be rejected upstream if they only support the PF, but no VFs. IMHO, that's = an unreasonable requirement. Don't get me wrong, I agree that it'd be great if all drivers would (be abl= e to) support the corresponding VFs. But in practice that's not always the case, so I'd rather have a common way= to let drivers assert what they support over going back to the "old model" of probing drivers, where we just rely on probe() to fail. > This temporary > weirdness of novacore should not be elevated to a core behavior that > people will misuse. It's not just nova-core, please see [1]. [1] https://lore.kernel.org/lkml/DD7TP31FEE92.2E0AKAHUOHVVF@kernel.org/