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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34A7AC433EF for ; Sat, 28 May 2022 00:10:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351215AbiE1AKo (ORCPT ); Fri, 27 May 2022 20:10:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229628AbiE1AKn (ORCPT ); Fri, 27 May 2022 20:10:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBE662AE1B for ; Fri, 27 May 2022 17:10:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 70EDAB82655 for ; Sat, 28 May 2022 00:10:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F234C385A9; Sat, 28 May 2022 00:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653696640; bh=deeVstLirzwzuUFVT4d8hFJpWp1D4Uv59omXQS1HX2U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OXjsg0eEE/QuD1GY66o/y7Z5tJRay7FvLyf1BQz2BayGY9tyrwdFVH84ejVCVOnGi ftgGZWsRgtQreThBtz4VPF6E+tj4w0ONPOS2yqHYcpiOfZRxcnl/3eQcbizxb7Hg6o i+xZkX0ZzVtKXzRUbdFHkDagE33fa/PIY6y05U0C8lFiAfHiIT8fD5ybaVhR2DaBi/ sKuyQS7SOtuwGSCI+RrFcsMeakdb05kjFPCUZm7KGmhHBEccmlww3TSBUJf8gYZrXk b53RcogfhmZ35eSLhpGofre/sAGvezSC5dZXzjtPS3e/P6igpu0A1SVm3nLhL5JYzw /XSfBaFibd3hw== Date: Fri, 27 May 2022 17:10:38 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: Ido Schimmel , Ido Schimmel , netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com, jiri@nvidia.com, petrm@nvidia.com, dsahern@gmail.com, andrew@lunn.ch, mlxsw@nvidia.com Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info Message-ID: <20220527171038.52363749@kernel.org> In-Reply-To: References: <20220502073933.5699595c@kernel.org> <20220523105640.36d1e4b3@kernel.org> <20220524110057.38f3ca0d@kernel.org> <20220525085054.70f297ac@kernel.org> <20220526103539.60dcb7f0@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 27 May 2022 09:27:47 +0200 Jiri Pirko wrote: > Okay. So the output of devlink dev info would be extended by > "components" nest. This nest would carry array of components which > contain versions. The name of the component is openin each array member > nest: > > $ devlink dev info > pci/0000:01:00.0: > driver mlxsw_spectrum2 > versions: > fixed: > hw.revision A0 > fw.psid MT_0000000199 > running: > fw.version 29.2010.2302 > fw 29.2010.2302 > components: > lc1: Is the "lc1" free-form or generated by the core based on subobjects? Is it carried as a string or object type + id? I guess my suggestion of a CLI mockup has proven its weakness :) > versions: > fixed: > hw.revision 0 > fw.psid MT_0000000111 > running: > fw 19.2010.1310 > ini.version 4 > lc2: > versions: > fixed: > hw.revision 0 > fw.psid MT_0000000111 > running: > fw 19.2010.1310 > ini.version 4 > someothercomponentname: > versions: > running: > fw: 888 > > Now on top of exsisting "devlink dev flash" cmd without component, user > may specify the component name from the array above: > > $ devlink dev flash pci/0000:01:00.0 component lc1 file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2 > > $ devlink dev flash pci/0000:01:00.0 component someothercomponentname file foo.bin > > Note this is generic vehicle, line cards would benefit but it is usable > for multiple ASIC FW partitions for example. > > Note that on "devlink dev flash" there is no change. This is implemented > currently. Only "devlink dev info" is extended to show the component > list. I sort of assumed that the DEVLINK_ATTR_INFO_VERSION_NAME is the component, the docs also use the word "component" for it. For the nfp for instance we had "fw.app" for the datapath microcode and "fw.mgmt" for the control processor. These are separate partitions on the flash. I don't think we ever implemented writing them separately but it's certainly was our internal plan at some point.