linux-kernel - Re: Synopsys Ethernet QoS Driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <899DC02E-84BB-489E-A1FE-5D8F3BB795B6@axis.com>
Date:   Wed, 23 Nov 2016 11:41:28 +0000
From:   Lars Persson <lars.persson@...s.com>
To:     Joao Pinto <Joao.Pinto@...opsys.com>
CC:     Giuseppe CAVALLARO <peppe.cavallaro@...com>,
        Rayagond Kokatanur <rayagond@...avyalabs.com>,
        Rabin Vincent <rabin@....in>, mued dib <kreptor@...il.com>,
        David Miller <davem@...emloft.net>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        netdev <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "CARLOS.PALMINHA@...opsys.com" <CARLOS.PALMINHA@...opsys.com>,
        Andreas Irestål <andire@...s.com>,
        "alexandre.torgue@...com" <alexandre.torgue@...com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Synopsys Ethernet QoS Driver


> 23 nov. 2016 kl. 12:11 skrev Joao Pinto <Joao.Pinto@...opsys.com>:
> 
> Hi Peppe and Lars,
> 
>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
>> Hello Joao, Lars.
>> 
>>> On 11/22/2016 3:16 PM, Joao Pinto wrote:
>>>>> Ok, it makes sense.
>>>>> Just for curiosity the target setup is the following:
>>>>> https://www.youtube.com/watch?v=8V-LB5y2Cos
>>>>> but instead of using internal drivers, we desire to use mainline drivers only.
>>>>> 
>>>>> Thanks!
>>> Regarding this subject, I am thinking of making the following adaption:
>>> 
>>> a) delete ethernet/synopsys
>>> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>>> 
>>> and send you a patch for you to evaluate. Both agree with the approach?
>>> To have a new work base would be important, because I will add to the "new"
>>> structure some missing QoS features like Multichannel support, CBS and later TSN.
>> 
>> IMO, we have to agree on a common strategy making the change for
>> net-next; I imaged the following steps:
> 
> Yes it makes totally sense.
> 
>> 
>> - to port missing feature or fixes from ethernet/synopsys
>>  inside the stmmac taking care about the documentation too.
> 
> @Lars: You are familiar with the synopsys qos driver. Could you please do this
> porting. You can also make an analysis of what to port and I can do the porting
> for you if you don't have the availability for it.

As my main duty is changing diapers until March next year, please go ahead with this step if you can spend time on it before I am back in office.

Rabin Vincent can review and test that the port works properly on our Artpec-chips that use dwc_eth_qos.c today.

The main porting step is to implement the device tree binding in bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict requirement that the phy is enabled when the SWR reset bit is set (it needs a tx clock to complete the reset).

- Lars

> 
>> - remove ethernet/synopsys
>> - rename ethernet/stmicro/stmmac to ethernet/synopsys
> 
> I volunteer to do this task.
> 
>> 
>>  These latest two have some relevant impacts.
>> 
>>  This change should be propagated to all the platforms that are using:
>>      CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
>>  plus device-tree compatibility.
> 
> I volunteer to do this task also.
> 
>> 
>> - enhance the stmmac with new features and new glue (part of these
>>  can be anticipated for sure).
> 
> I have to implement 3 new features for now, but I will take some time for it, so
> I would suggest to make the previous task and incrementally add features.
> 
>> 
>> what do you think? does it make sense? If yes, we can also
>> understand how/who starts.
>> 
>> Regards,
>> Peppe
> 
> Thanks and regards.
> 
> Joao
> 
>> 
>>> Thanks.
>> 
>