From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Vecera Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode Date: Thu, 24 May 2018 15:44:54 +0200 Message-ID: <7437d485-1eac-9619-3827-5af9b32b939e@redhat.com> References: <1527144984-31236-1-git-send-email-ilias.apalodimas@linaro.org> <20180524080528.GD2295@nanopsycho> <20180524084831.GA2759@apalos> <20180524125431.GB24557@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jiri Pirko , netdev@vger.kernel.org, grygorii.strashko@ti.com, ivan.khoronzhuk@linaro.org, nsekhar@ti.com, francois.ozog@linaro.org, yogeshs@ti.com, spatton@ti.com To: Andrew Lunn , Ilias Apalodimas Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:40604 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S966066AbeEXNpA (ORCPT ); Thu, 24 May 2018 09:45:00 -0400 In-Reply-To: <20180524125431.GB24557@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 24.5.2018 14:54, Andrew Lunn wrote: > On Thu, May 24, 2018 at 11:48:31AM +0300, Ilias Apalodimas wrote: >> On Thu, May 24, 2018 at 10:05:28AM +0200, Jiri Pirko wrote: >>> Thu, May 24, 2018 at 08:56:20AM CEST, ilias.apalodimas@linaro.org wrote: >>> Any reason you need cpu port? We don't need it in mlxsw and also in dsa. >> Yes i've seen that on mlxsw/rocker drivers and i was reluctant adding one here. >> The reason is that TI wants this configured differently from customer facing >> ports. Apparently there are existing customers already using the "feature". >> So OR'ing and adding the cpu port on every operation (add/del vlans add >> ucast/mcast entries etc) was less favoured. > > Hi Ilias > > Nice to see this device moving away from its custom model and towards > the switchdev model. +1 > Did you consider making a clean break from the existing code and write > a new driver. Let the existing customers using the existing > driver. Have the new switchdev driver fully conform to switchdev. I would also prefer fresh new driver. The existing one can be marked as 'bugfix-only' and later pertinently deprecated/removed. > > I don't like having this 'cpu' interface. As you say, it breaks the > switchhdev model. If we need to extend the switchdev model to support > some use case, lets do that. Please can you fully describe the use > cases, so we can discuss how to implement them cleanly within the > switchdev model. +1 Ivan