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 771F7C433EF for ; Tue, 26 Apr 2022 12:12:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346873AbiDZMPI (ORCPT ); Tue, 26 Apr 2022 08:15:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345832AbiDZMPH (ORCPT ); Tue, 26 Apr 2022 08:15:07 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 744A922502 for ; Tue, 26 Apr 2022 05:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=Dq4q2zah4CrB69PB06jhJaSWSlf9RvpQ/G+Wl2cmm24=; b=BkDetfgs+JuvhQ2Gw924xiZZwb +f8G1ijBnAnP1tuTpqCATDcOSaHFDraIQ9+zWyYt1/PlBPWusWD1mU81vbbjJLbbZdGAlQCX5M5u9 mDJ8ng9M/ddH1ovss+2+rsvjW4Wlm6FVNFQniKcyOQ/HJqPujxuixkrXxTNaIMqhLsRQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1njK2h-00HXxP-4Q; Tue, 26 Apr 2022 14:11:43 +0200 Date: Tue, 26 Apr 2022 14:11:43 +0200 From: Andrew Lunn To: Jiri Pirko Cc: Jakub Kicinski , Ido Schimmel , Ido Schimmel , netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com, jiri@nvidia.com, petrm@nvidia.com, dsahern@gmail.com, mlxsw@nvidia.com Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info Message-ID: References: <20220425034431.3161260-1-idosch@nvidia.com> <20220425090021.32e9a98f@kernel.org> <20220425125218.7caa473f@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > >> The idea (implemented in the next patchset) is to let these devices > >> expose their own "component name", which can then be plugged into the > >> existing flash command: > >> > >> $ devlink lc show pci/0000:01:00.0 lc 8 > >> pci/0000:01:00.0: > >> lc 8 state active type 16x100G > >> supported_types: > >> 16x100G > >> devices: > >> device 0 flashable true component lc8_dev0 > >> device 1 flashable false > >> device 2 flashable false > >> device 3 flashable false > >> $ devlink dev flash pci/0000:01:00.0 file some_file.mfa2 component lc8_dev0 > > > >IDK if it's just me or this assumes deep knowledge of the system. > >I don't understand why we need to list devices 1-3 at all. And they > >don't even have names. No information is exposed. > > There are 4 gearboxes on the line card. They share the same flash. So if > you flash gearbox 0, the rest will use the same FW. Is the flash big enough to hold four copies of the firmware? Listing all four devices gives you a path forward to allowing each device to have its own firmware. On the flip side, flashable false is not really true. I don't know this API at all, but are there any flags? Can you at least indicate it is shared? You could then have an output something like: device 0 flashable true shared component lc8_dev0 device 1 flashable true shared component lc8_dev0 device 2 flashable true shared component lc8_dev0 device 3 flashable true shared component lc8_dev0 so you get to see the sharing relationship. Andrew