linux-kernel - Re: [PATCH] PCI/pwrctrl: Only destroy alongside host bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <xg45pqki76l4v7lgdqsnv34agh5hxqscoabrkexnk2zbzewho5@5dmmk46yebua>
Date: Sat, 12 Jul 2025 22:56:38 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	linux-kernel@...r.kernel.org, Brian Norris <briannorris@...gle.com>
Subject: Re: [PATCH] PCI/pwrctrl: Only destroy alongside host bridge

On Fri, Jul 11, 2025 at 05:43:33PM GMT, Brian Norris wrote:
> From: Brian Norris <briannorris@...gle.com>
> 
> We have asymmetry w.r.t. pwrctrl device creation and destruction.
> pwrctrl devices are created by the host bridge, as part of scanning for
> child devices, but they are destroyed by the child device. This causes
> confusing behavior in cases like the following:
> 
> 1. PCI device is removed (e.g., via /sys/bus/pci/devices/*/remove);
>    pwrctrl device is also destroyed
> 2. pwrctrl driver is removed (e.g., rmmod)
> 3. pwrctrl driver is reloaded
> 
> One could expect #3 to re-bind to the pwrctrl device and re-power the
> device; but there's no device to bind to, so it remains off. Instead, we
> require a forced rescan (/sys/bus/pci/devices/*/rescan) to recreate the
> pwrctrl device(s) and restore power.
> 
> This asymmetry isn't required though; it makes more logical sense to
> retain the pwrctrl devices even without the PCI device, since pwrctrl is
> more of a logical ancestor than a child.
> 
> Additionally, Documentation/PCI/sysfs-pci.rst documents the behavior of
> step #1 (remove):
> 
>   The 'remove' file is used to remove the PCI device, by writing a
>   non-zero integer to the file. This does not involve any kind of
>   hot-plug functionality, e.g. powering off the device.
> 
> Instead, let's destroy a pwrctrl device only when its parent (the host
> bridge) is destroyed.
> 

Sounds good to me!

> We use of_platform_device_destroy(), since it's the logical inverse of
> pwrctrl creation (of_platform_device_create()). It performs more or less
> the same things pci_pwrctrl_unregister() did, with some added bonus of
> ensuring these are OF_POPULATED devices.
> 

If you take a look at commit f1536585588b ("PCI: Don't rely on
of_platform_depopulate() for reused OF-nodes"), you can realize that the PCI
core clears OF_POPULATED flag while removing the PCI device. So
of_platform_device_destroy() will do nothing.

- Mani

-- 
மணிவண்ணன் சதாசிவம்