linux-kernel - Re: [PATCH 00/12] staging: dpaa2-ethsw: add support for control interface traffic

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: <50fd8cf7-ab16-24ae-9216-b191f37defd3@nxp.com>
Date:   Tue, 5 Nov 2019 13:49:34 +0000
From:   Ioana Ciornei <ioana.ciornei@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: Re: [PATCH 00/12] staging: dpaa2-ethsw: add support for control
 interface traffic

On 05.11.2019 15:24, Greg KH wrote:
> On Tue, Nov 05, 2019 at 02:34:23PM +0200, Ioana Ciornei wrote:
>> This patch set adds support for Rx/Tx capabilities on switch port interfaces.
>> Also, control traffic is redirected through ACLs to the CPU in order to
>> enable proper STP protocol handling.
>>
>> The control interface is comprised of 3 queues in total: Rx, Rx error and
>> Tx confirmation.  In this patch set we only enable Rx and Tx conf. All
>> switch ports share the same queues when frames are redirected to the CPU.
>> Information regarding the ingress switch port is passed through frame
>> metadata - the flow context field of the descriptor. NAPI instances are
>> also shared between switch net_devices and are enabled when at least on
>> one of the switch ports .dev_open() was called and disabled when at least
>> one switch port is still up.
>>
>> The new feature is enabled only on MC versions greater than 10.19.0
>> (which is soon to be released).
> 
> I thought I asked for no new features until this code gets out of
> staging?  Only then can you add new stuff.  Please work to make that
> happen first.
> 
> thanks,
> 
> greg k-h
> 

Sorry but I do not remember your suggestion on first moving the driver 
out of staging.

Anyhow, I submitted against staging because in an earlier discussion[1] 
it was suggested to first add Rx/Tx capabilities before moving it:

"Ah. Does this also mean it cannot receive?

That makes some of this code pointless and untested.

I'm not sure we would be willing to move this out of staging until it
can transmit and receive."


I'm not sure how I should proceed here.

Thanks,
Ioana

[1] https://lkml.org/lkml/2019/8/9/892