From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Reduce the scope for a variable in pci_bridge_release_resources()
Date: Mon, 25 Aug 2025 13:13:06 +0300 (EEST) [thread overview]
Message-ID: <f848ff97-9118-3e4a-d07c-c5009a4c310c@linux.intel.com> (raw)
In-Reply-To: <599e9acf-886b-4394-86bb-099e062c5b2c@web.de>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
On Sat, 23 Aug 2025, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 23 Aug 2025 09:40:13 +0200
>
> * Move the definition for the local variable “old_flags”
> into an if branch.
> * Put the assignment for the local variable “type” on a separate line.
>
> The source code was transformed by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/pci/setup-bus.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 119f97b96480..38bf4e673bd7 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1714,7 +1714,6 @@ static void pci_bridge_release_resources(struct pci_bus *bus,
> {
> struct pci_dev *dev = bus->self;
> struct resource *r;
> - unsigned int old_flags;
> struct resource *b_res;
> int idx = 1;
>
> @@ -1751,7 +1750,9 @@ static void pci_bridge_release_resources(struct pci_bus *bus,
> /* If there are children, release them all */
> release_child_resources(r);
> if (!release_resource(r)) {
> - type = old_flags = r->flags & PCI_RES_TYPE_MASK;
> + unsigned int old_flags = r->flags & PCI_RES_TYPE_MASK;
> +
> + type = old_flags;
> pci_info(dev, "resource %d %pR released\n",
> PCI_BRIDGE_RESOURCES + idx, r);
> /* Keep the old size */
My series is going to remove these variable altogether. A) One shouldn't
be messing with type (flags) at all which this code the tried to work
around by carrying the type information over the code that cleared it, and
B) there's a gross hack in how type is being handled. Both are solved by
my series.
Although, now that you posted this patch, I ended up realizing there's a
transient problem in my series, the assignment to type got removed too
early (should only be removed along with the type related hack, will be
fixed by v2 of my series).
--
i.
prev parent reply other threads:[~2025-08-25 10:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-23 7:51 Markus Elfring
2025-08-25 10:13 ` Ilpo Järvinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f848ff97-9118-3e4a-d07c-c5009a4c310c@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Markus.Elfring@web.de \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®