From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 E9BC0378803 for ; Wed, 24 Jun 2026 19:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782329937; cv=none; b=Y4ifY1DP3OSSq+oyMuSspDmRCOM0qC/WEgONyvVAYaco5WNtkUS2zB2fqiwcbOzYT9JlN03oicI5KVAUTqH9tqC87yK3iQAczhQimwGuuvw3D8HjZIq0rdM5hM5w4v8j9DBHs70D9Yv0LE7kkOZpjZ3rD2q9AxbwKfeF/JeQ9mw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782329937; c=relaxed/simple; bh=/i3F8aVlRB09Jw0j8WKE0aoMUU83ZBv8ZxgBmJ4bEUk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VIg7cm22RNZXR7cZYFx40oZbHiiePqUWj/URuk5Q0+k5h8LhP+JoGZ806UYIjDcYfyzjEKQaqHZnJZ1dx1O0PCUvXWK+L2AdXwqEUMA6ARV52mzaSzH3gqivbNBmIBJ/lIp9fZ8/UM+12FFLJuxBV7ZT0di/r/k8Ie2ByZWvk04= 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=gsooBkNM; arc=none smtp.client-ip=209.85.128.44 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="gsooBkNM" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490b211ee6aso9379095e9.3 for ; Wed, 24 Jun 2026 12:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782329934; x=1782934734; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=5JvYdpn4YzE4MVNRAOjv5r8auqSp+Gt6NQ8Tln1OeLY=; b=gsooBkNMWS6LIhYN7RKhBboYGy16S0qKS18gkeqlAE3xlB2ANvgI9C9OCJ3cOsKSU5 ggUbYVm29e5HRjm42hrUu3jZHq7ZiHcBt7wJ2XvLhtnguqrDa6OL2UNCEZ8IJXqY/VHj /0WJ5B+yPkKwehdWqrGdJenKAeOM1XhhuTGmgFre3JwTFjc4AP1A+nBh3e326DjjxePH Z8LafAy8tym9LjL5R47xHj0D1T1muEsVmyW64o8BEttl9Aza3sLCJfnxNg4kLgKCkPAV S49c6s1UWrIJsXvdN/GxFB9LvvnzKmaJE2UgaJVyOCqbSxKVOG75dfUa34o2HqDOmiX7 dZRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782329934; x=1782934734; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5JvYdpn4YzE4MVNRAOjv5r8auqSp+Gt6NQ8Tln1OeLY=; b=mFkjk+bF9PRenk+NsuIr/UbRtJUxy0oVLpOf15jKx9Kj5/MPHmxvNKA28aPisgao5X vaKzEqPVQSKwpz54Utkoc7swcS1WOb3d5pQsAkcdCPJaNzp+1XPWZO5kuFHB9RCzTtgH XRMoiVkm5ENX9PuXnzIwJ+VDzfhNabQ8wz8W3h+4J6J6N4iKHX68s/hXSjTyGX8AiN9L g6wReu8D4TrsR40eBmJ8UoT0Uq5srFJ+/62QfZIjXJo5M7OD6io7+9vqMRato2sQRdTn YIDKwHVku5UKW+g/bEBEjpEfRAfZvrNLQUpfIinOZTNLjfmNcn3o4yvjQEVbbjGicI6e P8Pg== X-Forwarded-Encrypted: i=1; AFNElJ+YIbFOnqasOFzFb1eCo5lb+Sp1FsYK37j7WcBqXqw4Hrj8rUlQUB/3XxIWz1mRCtRmbIl6Hoq0E2T5rqs=@vger.kernel.org X-Gm-Message-State: AOJu0YxP7VkA6ul+TOF7F9etrma1ObKiFSubo9JXyaweaGSJbqjrFHqG Q61XbUU7bbk4HQLcU+Nye/TG+PbXN87ZJpQErI7wElkTOu7xBzrlrZ2z X-Gm-Gg: AfdE7cmnXFJlmnEdvltMTOV39dzqkPJ5UK8XdDW8x8YZ5Bz1dWnfT8xaJUpdAo7FFPV qyufnchzaB10FR+j10dliyGTDI28BVigLVSm4h9PxEXAycjGB65H+kN4g2eugAFDjx6Dhp3porg juvkI5DssXxC+c3Z/DL/CLzSxVi2nCyMvPMOXqgKYYlgO2ex9JVnHoDcuoccC9G1cQaobKTVpnF 7XGBD0GfZXJPkoi6iJk57PDeBHs+6258Hu6qTzPR8IG7LcdfCLkNFbp+Y9QsC9Q6Y/iaidSOqye ZecQ5yrYZ+f7Nm88w4WrKaqye9WBmdN1YriH1QOqZJwa4N7bxHSppB4c7XfyqptBrwAclkA8U6U AogjGZcC39HWoa5WByaQWu9d3aAQVxFjuJj/4j3VKvWDEloxBHwHwWZXYmsuIzgENVq8Lugbdc6 ZwKv3tfpqGYmPDVxl4Agn3os9w2DUflEF3fkxM8b0laBPuwYrl1Q== X-Received: by 2002:a05:600c:4ecb:b0:492:433a:53af with SMTP id 5b1f17b1804b1-49260858030mr72253305e9.16.1782329934022; Wed, 24 Jun 2026 12:38:54 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4926494f129sm5853685e9.0.2026.06.24.12.38.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 12:38:53 -0700 (PDT) Date: Wed, 24 Jun 2026 20:38:51 +0100 From: David Laight To: "Alexandre Courbot" Cc: "Zhi Wang" , , , , , , , , , , , , , , , , , , , , , , , , , , , , "Bjorn Helgaas" , Subject: Re: [PATCH v2 1/7] PCI/IOV: Return u16 from pci_sriov_get_totalvfs() Message-ID: <20260624203851.7f6c7be4@pumpkin> In-Reply-To: References: <20260622194353.1308872-1-zhiw@nvidia.com> <20260622194353.1308872-2-zhiw@nvidia.com> <20260624143937.50499c29@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Wed, 24 Jun 2026 23:59:56 +0900 "Alexandre Courbot" wrote: > On Wed Jun 24, 2026 at 10:39 PM JST, David Laight wrote: > > On Wed, 24 Jun 2026 21:40:52 +0900 > > "Alexandre Courbot" wrote: > > > >> On Tue Jun 23, 2026 at 4:43 AM JST, Zhi Wang wrote: > >> > pci_sriov_get_totalvfs() reports a VF count, not an errno-style > >> > status. It returns 0 when SR-IOV is unavailable or the device is not a > >> > PF, and otherwise returns the PF's driver_max_VFs value. > >> > > >> > driver_max_VFs is stored as a u16 in struct pci_sriov. It is derived > >> > from the SR-IOV TotalVFs field or from a driver-provided limit, so the > >> > implementation cannot return a negative value. > >> > > >> > Change the declaration, CONFIG_PCI_IOV stub, and implementation to > >> > return u16. Update callers to store the result in u16 variables, remove > >> > obsolete negative-value checks, and use unsigned format specifiers where > >> > needed. > >> > > >> > Cc: Bjorn Helgaas > >> > Cc: linux-pci@vger.kernel.org > >> > Signed-off-by: Zhi Wang > >> > >> Suggested-by: Alexandre Courbot > >> Link: https://lore.kernel.org/all/DETDILPA1GFY.27WND0TEC5352@nvidia.com/ > >> > >> > --- > >> > drivers/crypto/hisilicon/qm.c | 8 +++++--- > >> > drivers/crypto/intel/qat/qat_common/adf_sriov.c | 6 +++--- > >> > drivers/gpu/drm/xe/xe_sriov_pf.c | 6 ++---- > >> > drivers/misc/genwqe/card_base.c | 6 ++---- > >> > drivers/net/ethernet/cavium/thunder/nic_main.c | 2 +- > >> > drivers/net/ethernet/emulex/benet/be_main.c | 3 ++- > >> > drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 3 ++- > >> > drivers/net/ethernet/sfc/ef10_sriov.c | 2 +- > >> > >> I believe that you can avoid converting all these drivers in this patch. > >> The implicit `u16 -> int` conversion done by C should result in the > >> expected behavior, and it will be fewer Acked-by to collect. > > > > The generated code is also likely to be slightly better if the function > > return value is a 32bit value. > > > > Similarly you don't really want to do any kind of maths on local variables > > that aren't 32bit (or 64bit on 64bit builds). > > > > The fact that the domain of a value fits in 16 bits doesn't mean that > > it is better to use u16 - it is usually worse. > > Pretty much the only place u16 should be used is to reduce the size > > of structures. > > > > So it is probably correct to change the return type to unsigned int and > > remove the error return checks, but nothing else. > > For C, I agree that unsigned int is the safest type. > > Rust otoh does not do implicit integer promotion, and making it return a > `u16` carries useful range information. I wonder if we could have a > private `__pci_sriov_get_totalvfs` that returns a `u16`, make > `pci_sriov_get_totalvfs` promote it to an `unsigned int` and return it, > while the Rust bindings would invoke `__pci_sriov_get_totalvfs` so they > can expose a `u16`? That is getting silly, something will end up doing the masking to police the 16bit value - it isn't just the C rules, the ABI pass/return u16 in in 32bit registers (even on x86) so one side (or both) has to mask the value. Your rust code has the same problem. Add 1 to a u16 variable and code has to be added to mask the result to 16 bits. You won't see it on x86 because it has 16bit alu operations, about the only other cpu eoth them is m68k (I'm not sure about s390 - it is based on a very old instructions set). David