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 3C6D5C433EF for ; Tue, 26 Apr 2022 15:36:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352410AbiDZPjn (ORCPT ); Tue, 26 Apr 2022 11:39:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352399AbiDZPjm (ORCPT ); Tue, 26 Apr 2022 11:39:42 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 281EC15831 for ; Tue, 26 Apr 2022 08:36:35 -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=j9VAZH5eUvbC9WkY1+q41sBAmz2EBnK0lG2ak2ONIE8=; b=V8TKtus7N7QAWyllMKkFOOWOl4 cv3T/VOjTWbhJLeHl6h5NGueaBSU4Ot9cyAJnQshE+X1rlQOgG+WS3mI2xTKa8R8MCP6/SPmn2McI JMqEzJuFdIRVVLibvD+Dpf9PvfHOCqrrHnFWP6vMESkjh3PwvIbGYbNLI4dqoB81ioJQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1njNEp-00HZi0-RL; Tue, 26 Apr 2022 17:36:27 +0200 Date: Tue, 26 Apr 2022 17:36:27 +0200 From: Andrew Lunn To: Jiri Pirko Cc: Ido Schimmel , Jakub Kicinski , 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> 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 On Tue, Apr 26, 2022 at 04:05:43PM +0200, Jiri Pirko wrote: > Tue, Apr 26, 2022 at 03:45:48PM CEST, andrew@lunn.ch wrote: > >> Well, I got your point. If the HW would be designed in the way the > >> building blocks are exposed to the host, that would work. However, that > >> is not the case here, unfortunatelly. > > > >I'm with Jakub. It is the uAPI which matters here. It should look the > >same for a SoC style enterprise router and your discombobulated TOR > >router. How you talk to the different building blocks is an > >implementation detail. > > It's not that simple. Take the gearbox for example. You say bunch of > MDIO registers. ASIC FW has a custom SDK internally that is used to > talk to the gearbox. > > The flash, you say expose by MTD, but there is no access to it directly > from host. Can't be done. There are HW design limitations that are > blocking your concept. The MTD API and your SDK API are abstractions. You give it a blob of data and ask it to write it to the storage. Somehow that happens. Does user space need to know MTD or an SDK is being used? Does user space care? I would expect the same uAPI for both, here is a firmware blob, write it to storage. The driver knows if it needs to use the MTD API or the SDK API, it is all abstracted away in the driver. Andrew