From mboxrd@z Thu Jan 1 00:00:00 1970 From: Giuseppe CAVALLARO Subject: Re: Synopsys Ethernet QoS Driver Date: Mon, 21 Nov 2016 15:36:58 +0100 Message-ID: <937252db-9538-2cf6-c8fa-82b558531c51@st.com> References: <1dbb6047-2bbb-4d56-2a62-ab65a0254844@synopsys.com> <20161119135654.GA14079@lnxartpec.se.axis.com> <1248f4ce-4859-10e6-fef9-342ea543f8d4@synopsys.com> <87c8a24b-0812-7850-cb3f-7be691bab432@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: andreas.irestal@axis.com, alexandre.torgue@st.com, saeedm@mellanox.com, netdev , linux-kernel@vger.kernel.org, CARLOS.PALMINHA@synopsys.com, idosch@mellanox.com, mued dib , jiri@mellanox.com, Jeff Kirsher , David Miller , "linux-arm-kernel@lists.infradead.org" , lars.persson@axis.com To: Joao Pinto , Rayagond Kokatanur , Rabin Vincent Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: netdev.vger.kernel.org Hello Joao On 11/21/2016 2:48 PM, Joao Pinto wrote: > Synopsys QoS IP is a separated hardware component, so it should be reusable by > all implementations using it and so have its own "core driver" and platform + > pci glue drivers. This is necessary for example in hardware validation, where > you prototype an IP and instantiate its drivers and test it. > > Was there a strong reason to integrate QoS features directly in stmmac and not > in synopsys/dwc_eth_qos.*? We decided to enhance the stmmac on supporting the QoS for several reasons; for example the common APIs that the driver already exposed and actually suitable for other SYNP chips. Then, PTP, EEE, S/RGMII, MMC could be shared among different chips with a minimal effort. This meant a lot of code already ready. For sure, the net-core, Ethtool, mdio parts were reused. Same for the glue logic files. For the latter, this helped to easily bring-up new platforms also because the stmmac uses the HW cap register to auto-configure many parts of the MAC core, DMA and modules. This helped many users, AFAIK. For validation purpose, this is my experience, the stmmac helped a lot because people used the same code to validate different HW and it was easy to switch to a platform to another one in order to verify / check if the support was ok or if a regression was introduced. This is important for complex supports like PTP or EEE. Hoping this can help. Do not hesitate to contact me for further details peppe