From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 402s1T3q8KzF0nG for ; Sat, 17 Mar 2018 03:51:41 +1100 (AEDT) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2GGn9vV103432 for ; Fri, 16 Mar 2018 12:51:38 -0400 Received: from e14.ny.us.ibm.com (e14.ny.us.ibm.com [129.33.205.204]) by mx0a-001b2d01.pphosted.com with ESMTP id 2grg0vmxkb-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Fri, 16 Mar 2018 12:51:38 -0400 Received: from localhost by e14.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 16 Mar 2018 12:51:37 -0400 Subject: Re: [PATCH 2/3] rfi-flush: Make it possible to call setup_rfi_flush() again To: Michael Ellerman Cc: =?UTF-8?Q?Michal_Such=c3=a1nek?= , linuxppc-dev@lists.ozlabs.org References: <1518644021-17037-1-git-send-email-mauricfo@linux.vnet.ibm.com> <1518644021-17037-3-git-send-email-mauricfo@linux.vnet.ibm.com> <20180215081358.2f37cda4@naga.suse.cz> <87lgforngp.fsf@concordia.ellerman.id.au> <20180220180621.11265945@kitsune.suse.cz> <2bb5a110-3ea4-af5c-81fb-cf5350587dff@linux.vnet.ibm.com> <876069flhq.fsf@concordia.ellerman.id.au> <20180306135522.040707de@kitsune.suse.cz> <876060gq5s.fsf@concordia.ellerman.id.au> <20180313185916.3e4a0ea6@kitsune.suse.cz> <20180313193652.069ed57b@kitsune.suse.cz> <87lgesgl2y.fsf@concordia.ellerman.id.au> From: Mauricio Faria de Oliveira Date: Fri, 16 Mar 2018 13:51:32 -0300 MIME-Version: 1.0 In-Reply-To: <87lgesgl2y.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=utf-8; format=flowed Message-Id: <00189945-c147-4c8c-fa4a-515bcfdae6cb@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Michael, On 03/16/2018 11:18 AM, Michael Ellerman wrote: >> I still think the correct, informative messages are a good way to go:) > Yeah I agree. > > We probably want to do both, print what's available at boot, and print > what's actually patched when the patching happens. Nice. Not sure you had a chance to review yet, but 'PATCH v3 4/5' does exactly that :- ) I think its implementation of the latter part looks a bit strange, but I couldn't figure an elegant way to fit that in (either that one or string array indexed by flush-type possible values or a long if-else chain). I'd be happy with suggestions if it's preferred in some other way. cheers, Mauricio