* [PATCH] kexec: Export kexec_in_progress to modules
@ 2016-10-21 1:15 Florian Fainelli
2016-10-21 1:54 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Florian Fainelli @ 2016-10-21 1:15 UTC (permalink / raw)
To: netdev; +Cc: ebiederm, kexec, linux-kernel, davem, sfr, Florian Fainelli
The bcm_sf2 driver uses kexec_in_progress to know whether it can power
down an integrated PHY during shutdown, and can be built as a module.
Other modules may be using this in the future, so export it.
Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Eric, David, Stephen,
The offending commit is in David's net.git tree, so it would probably make
sense to route the fix through the same tree.
Thanks!
kernel/kexec_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 561675589511..786ab85a5452 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -59,6 +59,7 @@ size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
/* Flag to indicate we are going to kexec a new kernel */
bool kexec_in_progress = false;
+EXPORT_SYMBOL_GPL(kexec_in_progress);
/* Location of the reserved area for the crash kernel */
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] kexec: Export kexec_in_progress to modules
2016-10-21 1:15 [PATCH] kexec: Export kexec_in_progress to modules Florian Fainelli
@ 2016-10-21 1:54 ` David Miller
2016-10-21 5:26 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2016-10-21 1:54 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, ebiederm, kexec, linux-kernel, sfr
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 20 Oct 2016 18:15:16 -0700
> The bcm_sf2 driver uses kexec_in_progress to know whether it can power
> down an integrated PHY during shutdown, and can be built as a module.
> Other modules may be using this in the future, so export it.
>
> Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Eric, David, Stephen,
>
> The offending commit is in David's net.git tree, so it would probably make
> sense to route the fix through the same tree.
Ok, I'll apply this, thanks Florian.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] kexec: Export kexec_in_progress to modules
2016-10-21 1:54 ` David Miller
@ 2016-10-21 5:26 ` Eric W. Biederman
2016-10-21 14:13 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2016-10-21 5:26 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, netdev, kexec, linux-kernel, sfr
David Miller <davem@davemloft.net> writes:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Thu, 20 Oct 2016 18:15:16 -0700
>
>> The bcm_sf2 driver uses kexec_in_progress to know whether it can power
>> down an integrated PHY during shutdown, and can be built as a module.
>> Other modules may be using this in the future, so export it.
>>
>> Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> Eric, David, Stephen,
>>
>> The offending commit is in David's net.git tree, so it would probably make
>> sense to route the fix through the same tree.
>
> Ok, I'll apply this, thanks Florian.
Florian
I am completely confused why any driver would want to do this.
A reboot is semantically identical to a kexec restart. Always has been.
That is pwoering down your hardware during reboot is not safe.
The only thing that might save you is the hardware reset line being
toggled at which point your hardware is powered up again anyway.
So as far as I can tell you are advocating for a change to support a
driver doing something that is completely pointless. So no let's not
export this symbol. Please fix the driver to do something less
pointless instead.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] kexec: Export kexec_in_progress to modules
2016-10-21 5:26 ` Eric W. Biederman
@ 2016-10-21 14:13 ` David Miller
2016-10-21 18:37 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2016-10-21 14:13 UTC (permalink / raw)
To: ebiederm; +Cc: f.fainelli, netdev, kexec, linux-kernel, sfr
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 21 Oct 2016 00:26:55 -0500
> So as far as I can tell you are advocating for a change to support a
> driver doing something that is completely pointless. So no let's not
> export this symbol. Please fix the driver to do something less
> pointless instead.
FLorian explained his reasoning for doing what he is doing in this
specific driver and it made sense to me.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec: Export kexec_in_progress to modules
2016-10-21 14:13 ` David Miller
@ 2016-10-21 18:37 ` Eric W. Biederman
2016-10-21 18:48 ` Florian Fainelli
0 siblings, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2016-10-21 18:37 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, netdev, kexec, linux-kernel, sfr
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Fri, 21 Oct 2016 00:26:55 -0500
>
>> So as far as I can tell you are advocating for a change to support a
>> driver doing something that is completely pointless. So no let's not
>> export this symbol. Please fix the driver to do something less
>> pointless instead.
>
> FLorian explained his reasoning for doing what he is doing in this
> specific driver and it made sense to me.
What doesn't make sense to me is not doing that for any other kind of
reboot.
Of the 3 uses of kexec_in_progres in the kernel (not counting this one)
I think there is only one of them that is really valid. And that one
is only valid because it is the least horrible thing the pci layer can
do. (AKA it is a hack even there).
It really is nonsense having methods do different things depending on
context and that is why kexec_in_progress is not exeported.
As far as I can tell the use of kexec_in_progress winds up being
a fragile hack that will just cause more problems later on.
Florian is there a good readon why you don't just do?
static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
{
struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
/* For a kernel about to be kexec'd we want to keep the GPHY on for a
* successful MDIO bus scan to occur. If we did turn off the GPHY
* before (e.g: port_disable), this will also power it back on.
*/
if (priv->hw_params.num_gphy == 1)
bcm_sf2_gphy_enable_set(priv->dev->ds, true);
}
I certainly don't see anything in the changelog to explain why that
isn't done.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] kexec: Export kexec_in_progress to modules
2016-10-21 18:37 ` Eric W. Biederman
@ 2016-10-21 18:48 ` Florian Fainelli
0 siblings, 0 replies; 6+ messages in thread
From: Florian Fainelli @ 2016-10-21 18:48 UTC (permalink / raw)
To: Eric W. Biederman, David Miller; +Cc: netdev, kexec, linux-kernel, sfr
On 10/21/2016 11:37 AM, Eric W. Biederman wrote:
> David Miller <davem@davemloft.net> writes:
>
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Fri, 21 Oct 2016 00:26:55 -0500
>>
>>> So as far as I can tell you are advocating for a change to support a
>>> driver doing something that is completely pointless. So no let's not
>>> export this symbol. Please fix the driver to do something less
>>> pointless instead.
>>
>> FLorian explained his reasoning for doing what he is doing in this
>> specific driver and it made sense to me.
>
> What doesn't make sense to me is not doing that for any other kind of
> reboot.
>
> Of the 3 uses of kexec_in_progres in the kernel (not counting this one)
> I think there is only one of them that is really valid. And that one
> is only valid because it is the least horrible thing the pci layer can
> do. (AKA it is a hack even there).
>
> It really is nonsense having methods do different things depending on
> context and that is why kexec_in_progress is not exeported.
>
> As far as I can tell the use of kexec_in_progress winds up being
> a fragile hack that will just cause more problems later on.
>
> Florian is there a good readon why you don't just do?
Checking kexec_in_progress allowed not to turn the PHY on for a normal
reboot case, since we don't necessarily know when it will be
re-initialized next, so in that sense it's a power optimization that is
nice to have.
>
> static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
> {
> struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
>
> /* For a kernel about to be kexec'd we want to keep the GPHY on for a
> * successful MDIO bus scan to occur. If we did turn off the GPHY
> * before (e.g: port_disable), this will also power it back on.
> */
> if (priv->hw_params.num_gphy == 1)
> bcm_sf2_gphy_enable_set(priv->dev->ds, true);
> }
>
> I certainly don't see anything in the changelog to explain why that
> isn't done.
That would result in an identical behavior for what I am after, David,
shall I send a revert plus this?
--
Florian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-21 18:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-21 1:15 [PATCH] kexec: Export kexec_in_progress to modules Florian Fainelli
2016-10-21 1:54 ` David Miller
2016-10-21 5:26 ` Eric W. Biederman
2016-10-21 14:13 ` David Miller
2016-10-21 18:37 ` Eric W. Biederman
2016-10-21 18:48 ` Florian Fainelli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).