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 6E0F4C433F5 for ; Sat, 28 May 2022 19:11:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229639AbiE1TLR (ORCPT ); Sat, 28 May 2022 15:11:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229561AbiE1TLQ (ORCPT ); Sat, 28 May 2022 15:11:16 -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 6830E6D86A for ; Sat, 28 May 2022 12:11:08 -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 5A72BB80885 for ; Sat, 28 May 2022 19:02:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85525C34100; Sat, 28 May 2022 19:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653764574; bh=PENZKiL8VO6QpRh6gvJR4EMjrhAlK6L5DxB8rj5OXQw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e+eOvN2oF6uZ/PtGrQj/3ql0qGNApEyXcaWl5hhUsKpM7xkUupvwwnl8hzwSN7oep AtxyMR046KoyKy2mm19mk+7MkilD/1Z3mDXGroXm5LeCFsUhtBorV4A3kDeEuCuTAy W7POTrkdFoW5xELzACRS6NEKUUzSyyXy2Sm+6wCc3fS1dMfDrISXiaPsJK3kYhuGTA FtwCvISrphnhT1yEJjcP7aKzUuMlOsXfgOj28s/USvU0bLh49JoXJv5xRq2ECEhZiw XHgfAUJ5acG2I4Rc3SIz9o9HJk59WVxbHjpoy/Zczk/pCRrYydN9l2ABZ3VMnRrgIQ FYIvpMOALXBWA== Date: Sat, 28 May 2022 12:02:53 -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: <20220528120253.5200f80f@kernel.org> In-Reply-To: References: <20220523105640.36d1e4b3@kernel.org> <20220524110057.38f3ca0d@kernel.org> <20220525085054.70f297ac@kernel.org> <20220526103539.60dcb7f0@kernel.org> <20220527171038.52363749@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 Sat, 28 May 2022 11:09:01 +0200 Jiri Pirko wrote: > Sat, May 28, 2022 at 02:10:38AM CEST, kuba@kernel.org wrote: > > > >Is the "lc1" free-form or generated by the core based on subobjects? > >Is it carried as a string or object type + id? > > It could be both: > 1) for line cards I plan to have a helper to have this generated by core > 2) for other FW objects, it is up to the driver. Did you mean "either" or "both"? > >I guess my suggestion of a CLI mockup has proven its weakness :) > > I'm not sure I understand what you mean by this sentence. Could you > please be more blunt? You know, my english is not so good to understand > some hidden meanings :) The question of what kind of attribute "lc1" is carried in would had been answered in posting of a code, while CLI mockup doesn't provide such detail. > > > >I sort of assumed that the DEVLINK_ATTR_INFO_VERSION_NAME is the > >component, the docs also use the word "component" for it. > > Okay, that I didn't see. > > > > >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. > > Okay, so what you say it, we already have components in "devlink dev > info". Like you pointed out as an example: > fw.app > fw.mgmt > so the flash comment would be: > devlink dev flash pci/0000:01:00.0 component fw.app file foo.bin > devlink dev flash pci/0000:01:00.0 component fw.mgmt file bar.bin > ? Correct. > If yes, what should be the default in case component is not defined? Do > we need to expose it in "devlink dev info"? How? Not defined as in someone tries to flash component X but there is no version for X in info? > So to extend this existing facility with my line card example, we would > have: > > $ devlink dev info > pci/0000:01:00.0: > driver mlxsw_spectrum2 > versions: > fixed: > hw.revision A0 > fw.psid MT_0000000199 > lc1.hw.revision 0 > lc1.fw.psid MT_0000000111 > lc2.hw.revision 0 > lc2.fw.psid MT_0000000111 > running: > fw.version 29.2010.2302 > fw 29.2010.2302 > lc1.fw 19.2010.1310 > lc1.ini.version 4 > lc2.fw 19.2010.1310 > lc2.ini.version 4 > > And then: > devlink dev flash pci/0000:01:00.0 component lc1.fw file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2 > > Does this sound correct? I think I suggested something like that in the past, but back then I was assuming that lc FW would come from the same large FW bundle file as the control plan FW, and we would not have to use the component. Let's step back and look from the automation perspective again. Assuming we don't want to hardcode matching "lc$i" there how can a generic FW update service scan the dev info and decide on what dev flash command to fire off? > Also, to avoid free-form, I can imagine to have per-linecard info_get() op > which would be called for each line card from devlink_nl_info_fill() and > prefix the "lcX" automatically without driver being involved. > > Sounds good? Hm. That's moving the matryoshka-ing of the objects from the uAPI level to the internals. If we don't do the string prefix but instead pass the subobject info to the user space as an attribute per version we can at least avoid per-subobject commands (DEVLINK_CMD_LINECARD_INFO_GET). Much closer to how health reporters are implemented than how params are done, so I think it is a good direction. We still need to iron out how the automation can go over the main FW and sub-objects in a generic way. I still think full devlink sub-instance is better because we will end up needing params or health. Fake devices can be made with auxbus or otherwise. But if you really don't want sub-instances we can explore the above.