From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935047AbcJUSjk (ORCPT ); Fri, 21 Oct 2016 14:39:40 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:49810 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755245AbcJUSjh (ORCPT ); Fri, 21 Oct 2016 14:39:37 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: David Miller Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, sfr@canb.auug.org.au References: <1477012516-20470-1-git-send-email-f.fainelli@gmail.com> <20161020.215410.650162338407203719.davem@davemloft.net> <871szagtls.fsf@xmission.com> <20161021.101343.1389577512803674816.davem@davemloft.net> Date: Fri, 21 Oct 2016 13:37:26 -0500 In-Reply-To: <20161021.101343.1389577512803674816.davem@davemloft.net> (David Miller's message of "Fri, 21 Oct 2016 10:13:43 -0400 (EDT)") Message-ID: <87wph1eeft.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bxej8-0008J6-JI;;;mid=<87wph1eeft.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=75.170.125.99;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX187bDQNYttovj85kh29SxUJBjHu16sB5XY= X-SA-Exim-Connect-IP: 75.170.125.99 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4996] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;David Miller X-Spam-Relay-Country: X-Spam-Timing: total 286 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.1 (1.1%), b_tie_ro: 2.2 (0.8%), parse: 1.17 (0.4%), extract_message_metadata: 18 (6.4%), get_uri_detail_list: 1.79 (0.6%), tests_pri_-1000: 9 (3.1%), tests_pri_-950: 1.53 (0.5%), tests_pri_-900: 1.30 (0.5%), tests_pri_-400: 23 (8.1%), check_bayes: 22 (7.6%), b_tokenize: 8 (2.8%), b_tok_get_all: 7 (2.4%), b_comp_prob: 1.92 (0.7%), b_tok_touch_all: 2.8 (1.0%), b_finish: 0.70 (0.2%), tests_pri_0: 121 (42.1%), check_dkim_signature: 0.43 (0.2%), check_dkim_adsp: 3.0 (1.1%), tests_pri_500: 105 (36.7%), poll_dns_idle: 100 (34.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] kexec: Export kexec_in_progress to modules X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Miller 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