From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C13ECC433E3 for ; Mon, 27 Jul 2020 18:11:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A712E20714 for ; Mon, 27 Jul 2020 18:11:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730287AbgG0SLq (ORCPT ); Mon, 27 Jul 2020 14:11:46 -0400 Received: from mga07.intel.com ([134.134.136.100]:10205 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728556AbgG0SLp (ORCPT ); Mon, 27 Jul 2020 14:11:45 -0400 IronPort-SDR: E+dG6Nm5wyhDQ+Abghdf/4tjoRzLrKVxn1YvwGIzznsD0Lb/1PQZbbB7tkxJbb3GVg2Q1QsdGW upxsGeTxpXuA== X-IronPort-AV: E=McAfee;i="6000,8403,9695"; a="215625292" X-IronPort-AV: E=Sophos;i="5.75,403,1589266800"; d="scan'208";a="215625292" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2020 11:11:44 -0700 IronPort-SDR: exNFDbmq8C/jcBjzb83adJbMTbzke6VD1XoY6C2v0tQISOWher10rWwGlM2gEdPbwFAW0b6GTw MrnFDApdRhCg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,403,1589266800"; d="scan'208";a="303553167" Received: from jekeller-mobl1.amr.corp.intel.com (HELO [10.212.56.18]) ([10.212.56.18]) by orsmga002.jf.intel.com with ESMTP; 27 Jul 2020 11:11:44 -0700 Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update To: Jiri Pirko Cc: Jakub Kicinski , "netdev@vger.kernel.org" , Tom Herbert , Jiri Pirko , Jonathan Corbet , Michael Chan , Bin Luo , Saeed Mahameed , Leon Romanovsky , Ido Schimmel , Danielle Ratson References: <20200717183541.797878-1-jacob.e.keller@intel.com> <20200717183541.797878-7-jacob.e.keller@intel.com> <20200720100953.GB2235@nanopsycho> <20200720085159.57479106@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200721135356.GB2205@nanopsycho> <20200721100406.67c17ce9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200722105139.GA3154@nanopsycho> <02874ECE860811409154E81DA85FBB58C8AF3382@fmsmsx101.amr.corp.intel.com> <20200722095228.2f2c61b8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <7d3a4dfb-ca4d-039a-9fad-2dcb5dbd9600@intel.com> <20200726071834.GC2216@nanopsycho> From: Jacob Keller Organization: Intel Corporation Message-ID: <9f33b220-6f2c-4f67-6c1d-c676e02d9904@intel.com> Date: Mon, 27 Jul 2020 11:11:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.0.1 MIME-Version: 1.0 In-Reply-To: <20200726071834.GC2216@nanopsycho> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 7/26/2020 12:18 AM, Jiri Pirko wrote: > Wed, Jul 22, 2020 at 08:21:22PM CEST, jacob.e.keller@intel.com wrote: >> >> >> On 7/22/2020 9:52 AM, Jakub Kicinski wrote: >>> On Wed, 22 Jul 2020 15:30:05 +0000 Keller, Jacob E wrote: >>>>> So perhaps we can introduce something like "component mask", which would >>>>> allow to flash only part of the component. That is basically what Jacob >>>>> has, I would just like to have it well defined. >>>> >>>> So, we could make this selection a series of masked bits instead of a >>>> single enumeration value. >>> >>> I'd still argue that components (as defined in devlink info) and config >>> are pretty orthogonal. In my experience config is stored in its own >>> section of the flash, and some of the knobs are in no obvious way >>> associated with components (used by components). >>> >>> That said, if we rename the "component mask" to "update mask" that's >>> fine with me. >>> >>> Then we'd have >>> >>> bit 0 - don't overwrite config >>> bit 1 - don't overwrite identifiers >>> >>> ? >>> >>> Let's define a bit for "don't update program" when we actually need it. >>> >> >> >> Ok. And this can be later extended with additional bits with new >> meanings should the need arise. >> >> Additionally, drivers can ensure that the valid combination of bits is >> set. the drivers can reject requests for combinations that they do not >> support. > > Makes sense. > >> >> I can make that change. >> >> My preference is that "0" for a bit means do not overwrite while "1" >> means overwrite. This way, if/when additional bits are added, drivers >> won't need to be updated to reject such requests. If we make "1" the "do >> not overwrite" then we'd have a case where drivers must update to ensure >> they reject requests which don't set the bit. > > 0 should be default and driver should bahave accordingly. > Correct, and it's good to spell that out more clearly. Thanks, Jake > >> >> Thanks, >> Jake