All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, f.fainelli@gmail.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	sfr@canb.auug.org.au
Subject: Re: [PATCH] kexec: Export kexec_in_progress to modules
Date: Fri, 21 Oct 2016 00:26:55 -0500	[thread overview]
Message-ID: <871szagtls.fsf@xmission.com> (raw)
In-Reply-To: <20161020.215410.650162338407203719.davem@davemloft.net> (David Miller's message of "Thu, 20 Oct 2016 21:54:10 -0400 (EDT)")

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



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	sfr@canb.auug.org.au
Subject: Re: [PATCH] kexec: Export kexec_in_progress to modules
Date: Fri, 21 Oct 2016 00:26:55 -0500	[thread overview]
Message-ID: <871szagtls.fsf@xmission.com> (raw)
In-Reply-To: <20161020.215410.650162338407203719.davem@davemloft.net> (David Miller's message of "Thu, 20 Oct 2016 21:54:10 -0400 (EDT)")

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

  reply	other threads:[~2016-10-21  5:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21  1:15 [PATCH] kexec: Export kexec_in_progress to modules Florian Fainelli
2016-10-21  1:15 ` Florian Fainelli
2016-10-21  1:54 ` David Miller
2016-10-21  1:54   ` David Miller
2016-10-21  5:26   ` Eric W. Biederman [this message]
2016-10-21  5:26     ` Eric W. Biederman
2016-10-21 14:13     ` David Miller
2016-10-21 14:13       ` David Miller
2016-10-21 18:37       ` Eric W. Biederman
2016-10-21 18:37         ` Eric W. Biederman
2016-10-21 18:48         ` Florian Fainelli
2016-10-21 18:48           ` Florian Fainelli

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=871szagtls.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.