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  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]
Date:   Thu, 26 Oct 2017 11:08:40 +0100
From:   Jose Abreu <>
To:     Andrew Lunn <>
CC:     Florian Fainelli <>, <>,
        <>, <>,
        "David S. Miller" <>,
        Joao Pinto <>,
        Giuseppe Cavallaro <>,
        Alexandre Torgue <>,
        Rob Herring <>
Subject: Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for
 TSN parameters

Hi Andrew,

On 26-10-2017 10:03, Andrew Lunn wrote:
>> These parameters may also need to change in runtime depending on
>> the scheduled traffic. Unfortunately, net subsystem does not yet
>> support TSN so this will have to wait and for now we will use
>> fixed parameters.
> Hi Jose
> what you should do is help Linux get support for TSN. Please take part
> in this discussion:
> Test the RFC, make sure the concepts will work for your hardware. Make
> you hardware work with these RFC patches. Help drive TSN forward. Once
> the core TSN code lands, then you can post patches for your driver.

After reading more carefully the RFC I noticed that for now it
only supports CBS. CBS is already supported by stmmac since:
"net: stmmac: configuration of CBS in case of a TX AVB queue"
[1]. My main objective now is to add support for EST and FP
features in stmmac.

As I am a recent contributor to net subsytem I am afraid my
expertise won't be of much value for now as far as the RFC goes.

About my patches, what I think would be better now would be to
drop the configuration by DT and integrate the remaining
configuration, letting the EST parameters be populated by SoC
specific wrappers. I will then integrate this with the RFC
patches once they get in and I also intend to contribute with the
discussion once a new version is sent.

I need also to say that this was fully tested and its working as
expected so, there is no real setback in integrating this now and
it will save us time in the future because then we will only need
to implement the callbacks.

Best regards,
Jose Miguel Abreu


>     Andrew

Powered by blists - more mailing lists