From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751879AbdATR1v (ORCPT ); Fri, 20 Jan 2017 12:27:51 -0500 Received: from smtprelay2.synopsys.com ([198.182.60.111]:59156 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751303AbdATR1u (ORCPT ); Fri, 20 Jan 2017 12:27:50 -0500 Subject: Re: [RFC PATCH] net: stmicro: eQOS IP Core To: David Miller , References: <4584830fd1416af69ddb2e0168f78b1e343c33fe.1484914583.git.jpinto@synopsys.com> <20170120.112025.283503761726233382.davem@davemloft.net> <20170120.113447.2060254584042448007.davem@davemloft.net> CC: , , , From: Joao Pinto Message-ID: Date: Fri, 20 Jan 2017 17:27:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170120.113447.2060254584042448007.davem@davemloft.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.107.19.92] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ās 4:34 PM de 1/20/2017, David Miller escreveu: > From: Joao Pinto > Date: Fri, 20 Jan 2017 16:30:41 +0000 > >> Charade of renames? It is a bit strong, don't you agree? > > Not at all. To avoid this kind of "charade" comments, I sent an RFC, not an official patch to be applied. Just a suggestion to be analysed by network/ developers. > >> So you suggest to keep the driver called as dwmac4 when the IP is in fact eQOS? >> Where do you suggest to put the eQOS 5.x features? > > Since you are adding the new code, you can name the functions that implement > eQOS 5.x support however you like. You don't have to rename the dwmac4 code > in order to add support for new chip families. > The rename suggestion of the dwmac4_* files was because it is stating that they are for a GMAC4 IP Core that does not exist. The controller is eQOS that started in version 4.x and now is going to release a 5.x. My sugestion intention is to put things clear and well structured to everyone that wish to use the driver in the future. I understand that you maintain a busy subsystem, and backport is a pain, but it shouldn't avoid you improving its structure. You have duplicated drivers targeting the same IPs and I just trying to puts things clear to avoid that in the future. I am going to focus developing the new features for the eQOS IP, and if sometime you think about organizing or change the backport workflow I am available to help you. Joao Pinto