The shutdown() call is similar to the remove() call except the former does
not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
if it does.
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index d3af8d84f0d6..a1fe1a2ada48 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1340,6 +1340,15 @@ static int brcm_pcie_remove(struct platform_device *pdev)
return 0;
}
+static void brcm_pcie_shutdown(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ if (pcie->has_err_report)
+ brcm_unregister_die_notifiers(pcie);
+ __brcm_pcie_remove(pcie);
+}
+
static const struct of_device_id brcm_pcie_match[] = {
{ .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
{ .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
@@ -1460,6 +1469,7 @@ static const struct dev_pm_ops brcm_pcie_pm_ops = {
static struct platform_driver brcm_pcie_driver = {
.probe = brcm_pcie_probe,
.remove = brcm_pcie_remove,
+ .shutdown = brcm_pcie_shutdown,
.driver = {
.name = "brcm-pcie",
.of_match_table = brcm_pcie_match,
--
2.17.1
On 4/27/2021 10:51 AM, Jim Quinlan wrote:
> The shutdown() call is similar to the remove() call except the former does
> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> if it does.
>
> Signed-off-by: Jim Quinlan <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
--
Florian
Capitalize "Add" in the subject.
On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
> The shutdown() call is similar to the remove() call except the former does
> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> if it does.
This doesn't explain why shutdown() is necessary. "errors occur"
might be a hint, except that AFAICT, many similar drivers do invoke
pci_stop_root_bus() and pci_remove_root_bus() (several of them while
holding pci_lock_rescan_remove()), without implementing .shutdown().
It is ... unfortunate that there's such a variety of implementations
here. I don't believe these driver differences are all necessary
consequences of hardware differences.
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index d3af8d84f0d6..a1fe1a2ada48 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1340,6 +1340,15 @@ static int brcm_pcie_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static void brcm_pcie_shutdown(struct platform_device *pdev)
> +{
> + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
> +
> + if (pcie->has_err_report)
> + brcm_unregister_die_notifiers(pcie);
> + __brcm_pcie_remove(pcie);
> +}
> +
> static const struct of_device_id brcm_pcie_match[] = {
> { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> { .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
> @@ -1460,6 +1469,7 @@ static const struct dev_pm_ops brcm_pcie_pm_ops = {
> static struct platform_driver brcm_pcie_driver = {
> .probe = brcm_pcie_probe,
> .remove = brcm_pcie_remove,
> + .shutdown = brcm_pcie_shutdown,
> .driver = {
> .name = "brcm-pcie",
> .of_match_table = brcm_pcie_match,
> --
> 2.17.1
>
On Tue, May 25, 2021 at 5:18 PM Bjorn Helgaas <[email protected]> wrote:
>
> Capitalize "Add" in the subject.
>
> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
> > The shutdown() call is similar to the remove() call except the former does
> > not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> > if it does.
>
> This doesn't explain why shutdown() is necessary. "errors occur"
> might be a hint, except that AFAICT, many similar drivers do invoke
> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
> holding pci_lock_rescan_remove()), without implementing .shutdown().
>
> It is ... unfortunate that there's such a variety of implementations
> here. I don't believe these driver differences are all necessary
> consequences of hardware differences.
Fair enough, I'll dig into the error.
Regards,
Jim Quinlan
Broadcom STB
>
> > Signed-off-by: Jim Quinlan <[email protected]>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index d3af8d84f0d6..a1fe1a2ada48 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -1340,6 +1340,15 @@ static int brcm_pcie_remove(struct platform_device *pdev)
> > return 0;
> > }
> >
> > +static void brcm_pcie_shutdown(struct platform_device *pdev)
> > +{
> > + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
> > +
> > + if (pcie->has_err_report)
> > + brcm_unregister_die_notifiers(pcie);
> > + __brcm_pcie_remove(pcie);
> > +}
> > +
> > static const struct of_device_id brcm_pcie_match[] = {
> > { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> > { .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
> > @@ -1460,6 +1469,7 @@ static const struct dev_pm_ops brcm_pcie_pm_ops = {
> > static struct platform_driver brcm_pcie_driver = {
> > .probe = brcm_pcie_probe,
> > .remove = brcm_pcie_remove,
> > + .shutdown = brcm_pcie_shutdown,
> > .driver = {
> > .name = "brcm-pcie",
> > .of_match_table = brcm_pcie_match,
> > --
> > 2.17.1
> >
On Tue, May 25, 2021 at 4:18 PM Bjorn Helgaas <[email protected]> wrote:
>
> Capitalize "Add" in the subject.
>
> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
> > The shutdown() call is similar to the remove() call except the former does
> > not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> > if it does.
>
> This doesn't explain why shutdown() is necessary. "errors occur"
> might be a hint, except that AFAICT, many similar drivers do invoke
> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
> holding pci_lock_rescan_remove()), without implementing .shutdown().
>
> It is ... unfortunate that there's such a variety of implementations
> here. I don't believe these driver differences are all necessary
> consequences of hardware differences.
What's correct here?
This was on my radar and something we should get in front of. It's
only a matter of time until everyone is converting their drivers to
modules since that is now the Android WayTM. My plan here was to
register a devm hook to call pci_stop_root_bus() and
pci_remove_root_bus(). That way every driver doesn't have to implement
a remove() hook. Though maybe they all need to quiesce themselves
anyways.
Rob
On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
> Capitalize "Add" in the subject.
>
> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
>> The shutdown() call is similar to the remove() call except the former does
>> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
>> if it does.
>
> This doesn't explain why shutdown() is necessary. "errors occur"
> might be a hint, except that AFAICT, many similar drivers do invoke
> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
> holding pci_lock_rescan_remove()), without implementing .shutdown().
We have to implement .shutdown() in order to meet a certain power budget
while the chip is being put into S5 (soft off) state and still support
Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
power savings at the wall. We could probably add a word or two in a v2
that indicates this is done for power savings.
As far as the crash goes, if we call brcm_pcie_remove() directly from
brcm_pcie_shutdown() we see the following (this is in 5.4, but I have no
reason to believe mainline is different):
# lspci
0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 7216 (rev 10)
0001:01:00.0 Network controller: Qualcomm Atheros AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)
# reboot -f
[ 8.465111] ------------[ cut here ]------------
[ 8.469771] pcieport 0001:00:00.0: disabling already-disabled device
[ 8.469817] WARNING: CPU: 3 PID: 1656 at drivers/pci/pci.c:1945
pci_disable_device+0x78/0xd0
[ 8.484631] Modules linked in:
[ 8.487695] CPU: 3 PID: 1656 Comm: reboot Not tainted
5.4.120-1.1pre-g231f2cfa989a #4
[ 8.495537] Hardware name: BCX972160DV (DT)
[ 8.499728] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 8.504527] pc : pci_disable_device+0x78/0xd0
[ 8.508891] lr : pci_disable_device+0x78/0xd0
[ 8.513254] sp : ffffffc014d33aa0
[ 8.516572] x29: ffffffc014d33aa0 x28: ffffff809deac800
[ 8.521894] x27: ffffff809e23a5b0 x26: ffffff809e23a490
[ 8.527214] x25: 0000000000000000 x24: ffffff809cf9f000
[ 8.532535] x23: ffffffc011d13090 x22: 0000000000000000
[ 8.537856] x21: 0000000000000000 x20: ffffff809cf9f0b0
[ 8.543175] x19: ffffff809cf9f000 x18: 000000000000000a
[ 8.548495] x17: 0000000000000000 x16: 0000000000000000
[ 8.553816] x15: 00000000000718d7 x14: 0720072007200720
[ 8.559138] x13: 0720072007200720 x12: 0720072007200720
[ 8.564458] x11: 0720072007200720 x10: 0720072007200720
[ 8.569777] x9 : 0720072007200720 x8 : 656c62617369642d
[ 8.575098] x7 : 79646165726c6120 x6 : ffffffc011dc3630
[ 8.580417] x5 : 0000000000000038 x4 : 0000000000000000
[ 8.585737] x3 : 0000000000000000 x2 : 0000000000000000
[ 8.591058] x1 : 73b2329426297100 x0 : 0000000000000000
[ 8.596379] Call trace:
[ 8.598832] pci_disable_device+0x78/0xd0
[ 8.602852] pcie_port_device_remove+0x3c/0x48
[ 8.607304] pcie_portdrv_remove+0x5c/0x8c
[ 8.611408] pci_device_remove+0x98/0xe8
[ 8.615341] device_release_driver_internal+0xb0/0x188
[ 8.620487] device_release_driver+0x28/0x34
[ 8.624765] pci_stop_bus_device+0x40/0xa8
[ 8.628867] pci_stop_root_bus+0x58/0x64
[ 8.632797] brcm_pcie_remove+0x24/0x70
[ 8.636640] brcm_pcie_shutdown+0x20/0x2c
[ 8.640655] platform_drv_shutdown+0x2c/0x38
[ 8.644934] device_shutdown+0x16c/0x1e0
[ 8.648865] kernel_restart_prepare+0x44/0x50
[ 8.653229] kernel_restart+0x20/0x68
[ 8.656896] __do_sys_reboot+0x158/0x200
[ 8.660816] __arm64_sys_reboot+0x2c/0x38
[ 8.664833] el0_svc_common.constprop.2+0xe8/0x168
[ 8.669631] el0_svc_handler+0x34/0x80
[ 8.673388] el0_svc+0x8/0x1fc
[ 8.676447] ---[ end trace 778d7966a5ef8213 ]---
[ 8.694539] pci_bus 0001:01: busn_res: [bus 01] is released
[ 8.700279] pci_bus 0001:00: busn_res: [bus 00-ff] is released
[ 8.710206] reboot: Restarting system
>
> It is ... unfortunate that there's such a variety of implementations
> here. I don't believe these driver differences are all necessary
> consequences of hardware differences.
Yes, that is a bit unfortunate, Rob's idea to consolidate the
implementation sounds good and we can definitively test that.
>
>> Signed-off-by: Jim Quinlan <[email protected]>
>> ---
>> drivers/pci/controller/pcie-brcmstb.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
>> index d3af8d84f0d6..a1fe1a2ada48 100644
>> --- a/drivers/pci/controller/pcie-brcmstb.c
>> +++ b/drivers/pci/controller/pcie-brcmstb.c
>> @@ -1340,6 +1340,15 @@ static int brcm_pcie_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static void brcm_pcie_shutdown(struct platform_device *pdev)
>> +{
>> + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
>> +
>> + if (pcie->has_err_report)
>> + brcm_unregister_die_notifiers(pcie);
>> + __brcm_pcie_remove(pcie);
>> +}
>> +
>> static const struct of_device_id brcm_pcie_match[] = {
>> { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
>> { .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
>> @@ -1460,6 +1469,7 @@ static const struct dev_pm_ops brcm_pcie_pm_ops = {
>> static struct platform_driver brcm_pcie_driver = {
>> .probe = brcm_pcie_probe,
>> .remove = brcm_pcie_remove,
>> + .shutdown = brcm_pcie_shutdown,
>> .driver = {
>> .name = "brcm-pcie",
>> .of_match_table = brcm_pcie_match,
>> --
>> 2.17.1
>>
--
Florian
On Wed, May 26, 2021 at 10:03:47AM -0700, Florian Fainelli wrote:
> On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
> > On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
> >> The shutdown() call is similar to the remove() call except the former does
> >> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> >> if it does.
> >
> > This doesn't explain why shutdown() is necessary. "errors occur"
> > might be a hint, except that AFAICT, many similar drivers do invoke
> > pci_stop_root_bus() and pci_remove_root_bus() (several of them while
> > holding pci_lock_rescan_remove()), without implementing .shutdown().
>
> We have to implement .shutdown() in order to meet a certain power budget
> while the chip is being put into S5 (soft off) state and still support
> Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
> power savings at the wall. We could probably add a word or two in a v2
> that indicates this is done for power savings.
"Saving power" is a great reason to do this. But we still need to
connect this to the driver model and the system-level behavior
somehow.
The pci_driver comment says @shutdown is to "stop idling DMA
operations" and it hooks into reboot_notifier_list in kernel/sys.c.
That's incorrect or at least incomplete because reboot_notifier_list
isn't mentioned at all in kernel/sys.c, and I don't see the connection
between @shutdown and reboot_notifier_list.
AFAICT, @shutdown is currently used in this path:
kernel_restart_prepare or kernel_shutdown_prepare
device_shutdown
dev->bus->shutdown
pci_device_shutdown # pci_bus_type.shutdown
drv->shutdown
so we're going to either reboot or halt/power-off the entire system,
and we're not going to use this device again until we're in a
brand-new kernel and we re-enumerate the device and re-register the
driver.
I'm not quite sure how either of those fits into the power-saving
reason. I guess going to S5 is probably via the kernel_power_off()
path and that by itself doesn't turn off as much power to the PCIe
controller as it could? And this new .shutdown() method will get
called in that path and will turn off more power, but will still leave
enough for wake-on-LAN to work? And when we *do* wake from S5,
obviously that means a complete boot with a new kernel.
Bjorn
On 6/3/21 10:23 AM, Bjorn Helgaas wrote:
> On Wed, May 26, 2021 at 10:03:47AM -0700, Florian Fainelli wrote:
>> On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
>>> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
>>>> The shutdown() call is similar to the remove() call except the former does
>>>> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
>>>> if it does.
>>>
>>> This doesn't explain why shutdown() is necessary. "errors occur"
>>> might be a hint, except that AFAICT, many similar drivers do invoke
>>> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
>>> holding pci_lock_rescan_remove()), without implementing .shutdown().
>>
>> We have to implement .shutdown() in order to meet a certain power budget
>> while the chip is being put into S5 (soft off) state and still support
>> Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
>> power savings at the wall. We could probably add a word or two in a v2
>> that indicates this is done for power savings.
>
> "Saving power" is a great reason to do this. But we still need to
> connect this to the driver model and the system-level behavior
> somehow.
>
> The pci_driver comment says @shutdown is to "stop idling DMA
> operations" and it hooks into reboot_notifier_list in kernel/sys.c.
> That's incorrect or at least incomplete because reboot_notifier_list
> isn't mentioned at all in kernel/sys.c, and I don't see the connection
> between @shutdown and reboot_notifier_list.
>
> AFAICT, @shutdown is currently used in this path:
>
> kernel_restart_prepare or kernel_shutdown_prepare
> device_shutdown
> dev->bus->shutdown
> pci_device_shutdown # pci_bus_type.shutdown
> drv->shutdown
>
> so we're going to either reboot or halt/power-off the entire system,
> and we're not going to use this device again until we're in a
> brand-new kernel and we re-enumerate the device and re-register the
> driver.
>
> I'm not quite sure how either of those fits into the power-saving
> reason. I guess going to S5 is probably via the kernel_power_off()
> path and that by itself doesn't turn off as much power to the PCIe
> controller as it could? And this new .shutdown() method will get
> called in that path and will turn off more power, but will still leave
> enough for wake-on-LAN to work? And when we *do* wake from S5,
> obviously that means a complete boot with a new kernel.
Correct, the S5 shutdown is via kernel_power_off() and will turn off all
that we can in the PCIe root complex and its PHY, drop the PCIe link to
the end-point which signals that the end-point can enter its own suspend
logic, too. And yes, when we do wake-up from S5 it means booting a
completely new kernel. S5 is typically implemented in our chips by
keeping just a little bit of logic active to service wake-up events
(infrared remotes, GPIOs, RTC, etc.).
--
Florian
On Thu, Jun 03, 2021 at 10:30:37AM -0700, Florian Fainelli wrote:
> On 6/3/21 10:23 AM, Bjorn Helgaas wrote:
> > On Wed, May 26, 2021 at 10:03:47AM -0700, Florian Fainelli wrote:
> >> On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
> >>> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
> >>>> The shutdown() call is similar to the remove() call except the former does
> >>>> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> >>>> if it does.
> >>>
> >>> This doesn't explain why shutdown() is necessary. "errors occur"
> >>> might be a hint, except that AFAICT, many similar drivers do invoke
> >>> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
> >>> holding pci_lock_rescan_remove()), without implementing .shutdown().
> >>
> >> We have to implement .shutdown() in order to meet a certain power budget
> >> while the chip is being put into S5 (soft off) state and still support
> >> Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
> >> power savings at the wall. We could probably add a word or two in a v2
> >> that indicates this is done for power savings.
> >
> > "Saving power" is a great reason to do this. But we still need to
> > connect this to the driver model and the system-level behavior
> > somehow.
> >
> > The pci_driver comment says @shutdown is to "stop idling DMA
> > operations" and it hooks into reboot_notifier_list in kernel/sys.c.
> > That's incorrect or at least incomplete because reboot_notifier_list
> > isn't mentioned at all in kernel/sys.c, and I don't see the connection
> > between @shutdown and reboot_notifier_list.
> >
> > AFAICT, @shutdown is currently used in this path:
> >
> > kernel_restart_prepare or kernel_shutdown_prepare
> > device_shutdown
> > dev->bus->shutdown
> > pci_device_shutdown # pci_bus_type.shutdown
> > drv->shutdown
> >
> > so we're going to either reboot or halt/power-off the entire system,
> > and we're not going to use this device again until we're in a
> > brand-new kernel and we re-enumerate the device and re-register the
> > driver.
> >
> > I'm not quite sure how either of those fits into the power-saving
> > reason. I guess going to S5 is probably via the kernel_power_off()
> > path and that by itself doesn't turn off as much power to the PCIe
> > controller as it could? And this new .shutdown() method will get
> > called in that path and will turn off more power, but will still leave
> > enough for wake-on-LAN to work? And when we *do* wake from S5,
> > obviously that means a complete boot with a new kernel.
>
> Correct, the S5 shutdown is via kernel_power_off() and will turn off all
> that we can in the PCIe root complex and its PHY, drop the PCIe link to
> the end-point which signals that the end-point can enter its own suspend
> logic, too. And yes, when we do wake-up from S5 it means booting a
> completely new kernel. S5 is typically implemented in our chips by
> keeping just a little bit of logic active to service wake-up events
> (infrared remotes, GPIOs, RTC, etc.).
Which part of that does this patch change? Is it that the new
.shutdown() turns off more power than machine_power_off() does by
itself?
Bjorn
On 6/3/21 1:58 PM, Bjorn Helgaas wrote:
> On Thu, Jun 03, 2021 at 10:30:37AM -0700, Florian Fainelli wrote:
>> On 6/3/21 10:23 AM, Bjorn Helgaas wrote:
>>> On Wed, May 26, 2021 at 10:03:47AM -0700, Florian Fainelli wrote:
>>>> On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
>>>>> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
>>>>>> The shutdown() call is similar to the remove() call except the former does
>>>>>> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
>>>>>> if it does.
>>>>>
>>>>> This doesn't explain why shutdown() is necessary. "errors occur"
>>>>> might be a hint, except that AFAICT, many similar drivers do invoke
>>>>> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
>>>>> holding pci_lock_rescan_remove()), without implementing .shutdown().
>>>>
>>>> We have to implement .shutdown() in order to meet a certain power budget
>>>> while the chip is being put into S5 (soft off) state and still support
>>>> Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
>>>> power savings at the wall. We could probably add a word or two in a v2
>>>> that indicates this is done for power savings.
>>>
>>> "Saving power" is a great reason to do this. But we still need to
>>> connect this to the driver model and the system-level behavior
>>> somehow.
>>>
>>> The pci_driver comment says @shutdown is to "stop idling DMA
>>> operations" and it hooks into reboot_notifier_list in kernel/sys.c.
>>> That's incorrect or at least incomplete because reboot_notifier_list
>>> isn't mentioned at all in kernel/sys.c, and I don't see the connection
>>> between @shutdown and reboot_notifier_list.
>>>
>>> AFAICT, @shutdown is currently used in this path:
>>>
>>> kernel_restart_prepare or kernel_shutdown_prepare
>>> device_shutdown
>>> dev->bus->shutdown
>>> pci_device_shutdown # pci_bus_type.shutdown
>>> drv->shutdown
>>>
>>> so we're going to either reboot or halt/power-off the entire system,
>>> and we're not going to use this device again until we're in a
>>> brand-new kernel and we re-enumerate the device and re-register the
>>> driver.
>>>
>>> I'm not quite sure how either of those fits into the power-saving
>>> reason. I guess going to S5 is probably via the kernel_power_off()
>>> path and that by itself doesn't turn off as much power to the PCIe
>>> controller as it could? And this new .shutdown() method will get
>>> called in that path and will turn off more power, but will still leave
>>> enough for wake-on-LAN to work? And when we *do* wake from S5,
>>> obviously that means a complete boot with a new kernel.
>>
>> Correct, the S5 shutdown is via kernel_power_off() and will turn off all
>> that we can in the PCIe root complex and its PHY, drop the PCIe link to
>> the end-point which signals that the end-point can enter its own suspend
>> logic, too. And yes, when we do wake-up from S5 it means booting a
>> completely new kernel. S5 is typically implemented in our chips by
>> keeping just a little bit of logic active to service wake-up events
>> (infrared remotes, GPIOs, RTC, etc.).
>
> Which part of that does this patch change? Is it that the new
> .shutdown() turns off more power than machine_power_off() does by
> itself?
Yes, with pcie-brcmstb.c providing a .shutdow() callback we have a
chance to turn off our PCIe PHY and the RC's digital clock which would
not be able to do otherwise.
--
Florian