[{"id":3688165,"web_url":"http://patchwork.ozlabs.org/comment/3688165/","msgid":"<20260508050926.821E2C2BCB0@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T05:09:25","subject":"Re: [PATCH v7 19/24] PCI: Add macros for legacy I/O and memory\n address space sizes","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:\n- [Low] PCI_LEGACY_IO_SIZE macro is defined with an incorrect size of (SZ_64K - 1).\n--\n\ncommit d53406577948bbef31acd8d9cf7f8f8d4aed412a\nAuthor: Krzysztof Wilczyński <kwilczynski@kernel.org>\n\nPCI: Add macros for legacy I/O and memory address space sizes\n\nThis commit adds defines for the standard PCI legacy address space sizes\nto replace raw literals used by legacy sysfs attributes. It then updates\nthe sysfs code to use these newly added macros.\n\n> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c\n> index a6451bbf69a8c..7ba12b2abe486 100644\n> --- a/drivers/pci/pci-sysfs.c\n> +++ b/drivers/pci/pci-sysfs.c\n> @@ -1019,7 +1019,7 @@ void pci_create_legacy_files(struct pci_bus *b)\n>  \n>  \tsysfs_bin_attr_init(b->legacy_io);\n>  \tb->legacy_io->attr.name = \"legacy_io\";\n> -\tb->legacy_io->size = 0xffff;\n> +\tb->legacy_io->size = PCI_LEGACY_IO_SIZE;\n>  \tb->legacy_io->attr.mode = 0600;\n\n[ ... ]\n\n> diff --git a/include/linux/pci.h b/include/linux/pci.h\n> index c56f2cf0d2ab5..e37677a8dd3ca 100644\n> --- a/include/linux/pci.h\n> +++ b/include/linux/pci.h\n\n[ ... ]\n\n> @@ -1169,6 +1170,10 @@ enum {\n>  /* These external functions are only available when PCI support is enabled */\n>  #ifdef CONFIG_PCI\n>  \n> +/* PCI legacy I/O port and memory address space sizes. */\n> +#define PCI_LEGACY_IO_SIZE\t(SZ_64K - 1)\n\nIs this macro value mathematically correct for a size definition?\n\nThe legacy PCI I/O port space spans ports 0x0000 through 0xFFFF, meaning\nits total size is exactly 64 KiB.\n\nWhile the original sysfs code hardcoded 0xffff as the file size (which this\npatch intentionally maintains), exposing this off-by-one limit globally under\na SIZE naming convention seems potentially confusing.\n\nIf other subsystems start using PCI_LEGACY_IO_SIZE for memory allocations\nor loop bounds, could this lead to unexpected truncations? Might it make\nsense to define the true size as SZ_64K, and handle the off-by-one quirk\ndirectly at the sysfs site instead?\n\n> +#define PCI_LEGACY_MEM_SIZE\tSZ_1M\n> +\n>  extern unsigned int pci_flags;","headers":{"Return-Path":"\n <linux-pci+bounces-54221-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=H6r3LdNZ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-54221-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"H6r3LdNZ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBccB3dMLz1yJq\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 08 May 2026 15:09:30 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 85267301CA57\n\tfor <incoming@patchwork.ozlabs.org>; Fri,  8 May 2026 05:09:28 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 41EA632692B;\n\tFri,  8 May 2026 05:09:27 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EEF7286A7\n\tfor <linux-pci@vger.kernel.org>; Fri,  8 May 2026 05:09:26 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 821E2C2BCB0;\n\tFri,  8 May 2026 05:09:26 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778216967; cv=none;\n b=KvFXGOkFyZs6DIcIb9+0UvOS/Rf7WLkatEvG2+J0FWJ1bGu6CJ1WbXrmy/P0AED5QCNfhTpPT6eHFE2LIyHCgJ7GykpoGdbFSH+2USzBC0IgAvGqiyD9Y0F8nK7LPgQ7G+bdXBKfO3Yig4WEmVsyLJiU3uAxpWd8n089QfRIGNI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778216967; c=relaxed/simple;\n\tbh=iWlRv61hmX6VI1/ndInYVh46DL6bAnQciSLGswPwxXA=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=ZinW0WbDp3H6YiYVsO26ltDit9YARjR7MjKXaH40gfzwBV+0Q60oqWYXZw+Ge57SKU0VurYRyu3h2k/EauOkuo5niKJVWeh43JEr2FTqEp7HoLCW+/L0rsL5blNMNzHw8ekH8x1GM0PNF98ox2DqJIWMhWfVzwcalZR0JV1qHWQ=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=H6r3LdNZ; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778216966;\n\tbh=iWlRv61hmX6VI1/ndInYVh46DL6bAnQciSLGswPwxXA=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=H6r3LdNZFZbpk5hWhrpBCbxhJ5tsIwb+mmhiF+QMaze/2o7xaJMyncdjZUid9dKmt\n\t OmG6Kf4UFm8OY3HqdZlkI/Cd3K6FXYc7G4RQQrFURSkAyqYAEPyQYOT894hV940Enk\n\t WqZBxZ8Ux2+BhnRYTYIq3lvD02wpmDCmLdxiIhxBPrEmx9tIK6oMSYvWnzil+bi+mj\n\t iykmbLVpdRCGM6hpHrqxLwnKfFfPKvOY+1AkOJoAY2jLdBCyYr5ZEss+Y8TFEq9Z3U\n\t d53tP3/bV9RPo8RCwiIYTOcme5G28dDTjGW+quywycPf8MdaRBj5vXKuxuYSwhwuGE\n\t AvYtTWq82gxJg==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v7 19/24] PCI: Add macros for legacy I/O and memory\n address space sizes","Reply-To":"sashiko@lists.linux.dev","To":"=?utf-8?q?Krzysztof_Wilczy=C5=84ski?= <kwilczynski@kernel.org>","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508043543.217179-20-kwilczynski@kernel.org>","References":"<20260508043543.217179-20-kwilczynski@kernel.org>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 05:09:25 +0000","Message-Id":"<20260508050926.821E2C2BCB0@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>"}}]