From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 92A082F6925 for ; Mon, 24 Nov 2025 21:42:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764020568; cv=none; b=FPRpRJ9p1qmMW7/vI4i6fMiPt4Aq5d7CuXlx068rCqxyzMvSmps6t+MO3jXk7bduDd5KEZ8RJTIRgWrQ2oPxZeAwzSwakBzVc/XcQhb882jDt3Ts+Meqgr99WIXKhFFTbxm/y+/hRyWJvwkLRyJBdQEj6jsVlqTkYiNK+KLaa14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764020568; c=relaxed/simple; bh=zMEVRNWtaJhEk6cA0gcGBz/uzupVdTWSN726LtO0lvk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Kdj9Y86RFgA/WmXK3R7B+m6Pv4rTQ/YLOzgpIFdcF/q1vMYlSvqDGk3eXLEJy7Hc/HwvBlDQEgPWJ1F64n1wCtjRUAOd5XkCjrsJwyg1+l3EtFtTt6krspA1D9k0Znt1v1Zgp0QBBxLM6NWlG982/gb9NihlzpUmTmrlVjqqwCE= 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=Jt+myOlg; arc=none smtp.client-ip=209.85.128.50 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="Jt+myOlg" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-47778b23f64so25478835e9.0 for ; Mon, 24 Nov 2025 13:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764020565; x=1764625365; 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=azjd/qcQrhADibLrfRmh6V9yy/7q2hObFD5GqSGj+Ao=; b=Jt+myOlgrJpKpEccYXnKuyWOoANrcHZ+GBemPK07AXRxyxkQmpC17iSXqlO9Zq1eXF uHfOvr6r/7suO/8yfTACYTtdOjGMjQGU3sw4RJGY3wGBnRfclVzS/Ao2f8dwTHf7MwaB FT3XPsCgj+ekI/1mhi+ZT9c8wowWL4mLZDIFzCH9PHIfkclAFjOsOrnsxsqgfKoJtlJo /IZywnF/U1TQniIQJkez1Xi34Q1npaeE75tqjk8BWwvZ0P+A/Y1K98yDuVONxDSeM176 fn35rI3Qu0+Sfdn1k0p0Hw6UBQ17sT9Pcs8sY4OviIZpC1xtP7WvuraS5HlkFFSc+ZwW 5CDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764020565; x=1764625365; 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=azjd/qcQrhADibLrfRmh6V9yy/7q2hObFD5GqSGj+Ao=; b=eADOu7dKbVOPRI4Pekfy5v4UfBClP+Hz85cFlYVC8JIPSFxfjd+s5gGxl1jTI5LeYY QmlvooE/8a9icHJCCQmfRr54L2NR5FEeb4Ji/dvy/dtSSTyaREE/M2xPf+k2fhySOt/u qOvBcLtKY30h61/W06ZDv2VRraPm0rjwqNBTXIK21VncblZ3rFG9n7tmWUH46NUN3Piw 3Cuxnoi4Pi2pvv1+fye+Edn8Bw9kZFef3nWMCr9CRCLPPjvmjxItAOFWeIxNihyxm981 sJCQsZhBL3eXFSE3C88jpxUodctugj027fcniDakNfRwZa7x6yvX6DNGODBS96h/OkW/ beaQ== X-Gm-Message-State: AOJu0Yz1LA+9tshLcxJRDIJtD95QqSL+lVdg57QbR6aq2W0EJqgeLz3C uVFxdhjlk8ez8x6vJBsB7IlUfb2Kzf1pgN13ysm5IfTRZLvgA9yd8Z7+ X-Gm-Gg: ASbGncsh/P73cYWuRXpqV+SCUqt2EpyslNmHgfeJs4gbJUYE2sDrc5diyDH8ISc/M5H 1tWTlr0cNFLNo77tVU07JIZRFK9udHc7ApEMC6nyP71tyTs8s37JeYZBwtshcYqFnW+CBBU5nj5 ELRHxJjEgX5ELnQFu7nsnrnJe6oKRbxiceqkXow9HVTAfGVq9Gwchne+Dq2I2qwpnbvn32rtyO6 wN9VxsKEG9EA0yw6YXgHH8uAcigX1D7dKA/hJXb29FOCnjPIQOtJiaJiXCp6rJL28iw8vqsVmBo gelzEAlJtp2JWoqkciU3gfm+3I5uto0pf8nue6ROEPjy7/sbDF7v8BcdRB2VHI5aXXgrfCZez93 VO4SXCXdYKiCdSIOkGYDMuJItaFfg0o34ibh4oZYsUaWbwAkE12J34tzR7+8e3FBolFW5gyceGA WaWI1mG90OyhP3T2eTG5aA12vHA4QteemrD/DvPlbYFkwulTXR6X88 X-Google-Smtp-Source: AGHT+IHTxSaOa2kt5YN5WfOGej0F6r+Gi9WzebbEtWvfagNddB3Q4SQPDmMcUntu1xCWwGqExiBVFA== X-Received: by 2002:a05:600c:a07:b0:477:a3d1:aafb with SMTP id 5b1f17b1804b1-477c115c657mr131509575e9.29.1764020564694; Mon, 24 Nov 2025 13:42:44 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42cb7fb9190sm30419112f8f.33.2025.11.24.13.42.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Nov 2025 13:42:44 -0800 (PST) Date: Mon, 24 Nov 2025 21:42:40 +0000 From: David Laight To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Bjorn Helgaas Subject: Re: [PATCH 25/44] drivers/pci: use min() instead of min_t() Message-ID: <20251124214240.03af61f9@pumpkin> In-Reply-To: <20251124210410.GA2708124@bhelgaas> References: <20251119224140.8616-26-david.laight.linux@gmail.com> <20251124210410.GA2708124@bhelgaas> 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 Mon, 24 Nov 2025 15:04:10 -0600 Bjorn Helgaas wrote: > On Wed, Nov 19, 2025 at 10:41:21PM +0000, david.laight.linux@gmail.com wrote: > > From: David Laight > > > > min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'. > > Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long' > > and so cannot discard significant bits. > > > > In this case although pci_hotplug_bus_size is 'long' it is constrained > > to be <= 255. > > > > Detected by an extra check added to min_t(). > > I don't mind applying this, but it sure would be nice to have a hint > at the max() and max_t() definitions about when and why to prefer one > over the other. When I've sorted out local commits for all the other 400 files I've had to change to get allmodconfig to build I'm going to look at minmax.h and checkpatch.pl. The current bit in checkpatch that suggests transforming min(a, (type)b) => min_t(type, a, b) isn't even a good idea. The latter is min((type)a, (type)b) - which isn't the same. at least in with min(a, (type)b)) the truncation is obvious. I think I'll try to get checkpatch to reject min_t(u8|s8|u16|s16, ... outright - remember the values get promoted the 'int'. Unless the code is doing something really obscure they can all be replaced with a plain min(). Then get minmax.h to reject u8 casts when one of the values is 255 (and u16 casts with 65535) - particularly for clamp_t(). That will error a small number of files - but only a handful. I need to find the #if that is set for a W=1 build so that I can 'error' more of the 'dodgy' cases. That might include all the u8|s8|u16|s16 ones. But I'll have to leave all the u32 casts of u64 values (on 64bit) for later (they are typically u32 and size_t). I've not yet looked for u32 casts of u64 values (long v long long) on 32bit. I suspect there are some real bugs there. Maybe I'll try to get them into the W=2 build no one does :-) I'm retired, need to find something to do ... (apart from getting to PoGo level 80) David