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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 56989C433DF for ; Sun, 16 Aug 2020 22:06:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3C88B206F4 for ; Sun, 16 Aug 2020 22:06:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729368AbgHPWGg (ORCPT ); Sun, 16 Aug 2020 18:06:36 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:55600 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgHPWGg (ORCPT ); Sun, 16 Aug 2020 18:06:36 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1k7QnQ-009d8a-4R; Mon, 17 Aug 2020 00:06:32 +0200 Date: Mon, 17 Aug 2020 00:06:32 +0200 From: Andrew Lunn To: Vladimir Oltean Cc: David Miller , netdev , Chris Healy , Vivien Didelot Subject: Re: [PATCH net-next 2/7] net: dsa: Add devlink regions support to DSA Message-ID: <20200816220632.GA2294711@lunn.ch> References: <20200816194316.2291489-1-andrew@lunn.ch> <20200816194316.2291489-3-andrew@lunn.ch> <20200816215009.m7ovmuwjme3lrl4g@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200816215009.m7ovmuwjme3lrl4g@skbuf> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > Could we perhaps open-code these from the drivers themselves? There's > hardly any added value in DSA providing a "helper" for creation of > devlink resources (regions, shared buffers, etc). It is something i considered. But we already have devlink wrappers. It would be odd to have some parts of devlink wrapped and other parts not. The wrapping of phys is also causing Russell King problems. Both phylink and devlink structures are mostly hidden away in the DSA core, but do leak a bit into the drivers. If we do change to open coding, would we remove the existing wrappers as well? > Take the ocelot/felix driver for example. ocelot/felix is just plain odd. We have to do a balancing act for it. We don't want to take stuff out of the core just for this one odd switch, at the detriment for other normal DSA drivers. Andrew