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 A8FE5C433DF for ; Tue, 28 Jul 2020 22:59:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B00D2075D for ; Tue, 28 Jul 2020 22:59:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729911AbgG1W75 (ORCPT ); Tue, 28 Jul 2020 18:59:57 -0400 Received: from mga12.intel.com ([192.55.52.136]:38502 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729744AbgG1W75 (ORCPT ); Tue, 28 Jul 2020 18:59:57 -0400 IronPort-SDR: LPGFYm22Y+1CoxJszDwx30k1w4c42L6A7deqx6tjK66cC6J2HgRCUzOax6PFpHipd6k7ULPcGv COVGKUV7L5Wg== X-IronPort-AV: E=McAfee;i="6000,8403,9696"; a="130887614" X-IronPort-AV: E=Sophos;i="5.75,408,1589266800"; d="scan'208";a="130887614" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2020 15:59:57 -0700 IronPort-SDR: QK9tqkkhyj4ovd8wcJdDdpDYFbArxqgT1ClRdBk3wOWwMHFO1JFZmNnS2o9WvF/xGRXbOE/mw7 L64B67MQTeeA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,408,1589266800"; d="scan'208";a="273704453" Received: from jekeller-mobl1.amr.corp.intel.com (HELO [10.212.32.199]) ([10.212.32.199]) by fmsmga008.fm.intel.com with ESMTP; 28 Jul 2020 15:59:56 -0700 Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update To: Jakub Kicinski Cc: Jiri Pirko , "netdev@vger.kernel.org" , Tom Herbert , Jiri Pirko , Jakub Kicinski , 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> <20200726071606.GB2216@nanopsycho> <20200728111950.GB2207@nanopsycho> <20200728100939.108f33f0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> From: Jacob Keller Organization: Intel Corporation Message-ID: Date: Tue, 28 Jul 2020 15:59:56 -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: <20200728100939.108f33f0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> 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/28/2020 10:09 AM, Jakub Kicinski wrote: > On Tue, 28 Jul 2020 09:58:44 -0700 Jacob Keller wrote: >> On 7/28/2020 4:19 AM, Jiri Pirko wrote: >>> Yes. Documentation is very easy to ignore unfortunatelly. The driver >>> developer has to be tight up by the core code and api, I believe. >> >> So I'm not sure what the best proposal here is. We do have a list of >> generic components, but given that each piece of HW has different >> elements, it's not always feasible to have fully generic names. Some of >> the names are driver specific. >> >> I guess we could use some system where components are "registered" when >> loading the devlink, so that they can be verified by the stack when used >> as a parameter for flash update? Perhaps take something like the >> table-driven approach used for infos and extend that into devlink core >> so that drivers basically register a table of the components which >> includes both a function callback that gets the version string as well >> as an indication of whether that component can be updated via flash_update? >> >> I know it would also be useful for ice to have a sort of "pre-info" >> callback that generates a context structure that is passed to each of >> the info callbacks. (that way a single up-front step could be to lookup >> the relevant information, and this is then forwarded to each of the >> formatter functions for each component). >> >> Am I on the right track here or just over-engineering? > > I don't understand why we're having this conversation. > > No driver right now uses the component name. > > AFAIU we agreed not to use the component name for config vs code. > > So you may as well remove the component name from the devlink op and > add a todo there saying "when adding component back, make sure it's > tightly coupled to info". > Another simpler option would be to just call .info_get and verify that the requested component appeared in that list. Ofcourse we'd be making this call every flash_update...