lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <8e634d55-8119-2a78-2358-80e88685112a@synopsys.com> Date: Mon, 21 Nov 2016 15:14:40 +0000 From: Joao Pinto <Joao.Pinto@...opsys.com> To: Giuseppe CAVALLARO <peppe.cavallaro@...com>, Joao Pinto <Joao.Pinto@...opsys.com>, Rayagond Kokatanur <rayagond@...avyalabs.com>, Rabin Vincent <rabin@....in> CC: mued dib <kreptor@...il.com>, David Miller <davem@...emloft.net>, "Jeff Kirsher" <jeffrey.t.kirsher@...el.com>, <jiri@...lanox.com>, <saeedm@...lanox.com>, <idosch@...lanox.com>, netdev <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <CARLOS.PALMINHA@...opsys.com>, <andreas.irestal@...s.com>, <alexandre.torgue@...com>, <lars.persson@...s.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: Synopsys Ethernet QoS Driver On 21-11-2016 15:03, Giuseppe CAVALLARO wrote: > On 11/21/2016 4:00 PM, Joao Pinto wrote: >> On 21-11-2016 14:36, Giuseppe CAVALLARO wrote: >>> 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 >> >> Thanks for the highly detailed info. >> My target application is to prototype the Ethernet QoS IP in a FPGA, with a PHY >> attached and make hardware validation. >> >> In your opinion a refactored stmmac with the missing QoS features would be >> suitable for it? > > I think so; somebody also added code for FPGA. > > In any case, step-by-step we can explore and understand > how to proceed. I wonder if you could start looking at the internal > of the stmmac. Then welcome doubts and open question... Yes I am going to do that thanks... taking my first steps in this IP :) > >> >> Thanks. > > welcome > > peppe > >> >>> >>> peppe >> >> >
Powered by blists - more mailing lists