netdev - Re: [PATCH net-next v2 1/3] net: stmicro: prepare dwmac4 core for mtl

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] [day] [month] [year] [list]

Message-Id: <20170217.134950.2083594587911600300.davem@davemloft.net>
Date:   Fri, 17 Feb 2017 13:49:50 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     Joao.Pinto@...opsys.com
Cc:     peppe.cavallaro@...com, alexandre.torgue@...com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/3] net: stmicro: prepare dwmac4 core for
 mtl

From: Joao Pinto <Joao.Pinto@...opsys.com>
Date: Fri, 17 Feb 2017 18:09:06 +0000

> 
> Hi David,
> 
> Às 6:02 PM de 2/17/2017, David Miller escreveu:
>> From: Joao Pinto <Joao.Pinto@...opsys.com>
>> Date: Thu, 16 Feb 2017 11:19:39 +0000
>> 
>>> This patch adds the following features:
>>>
>>> a) RX and TX scheduling algorithm configuration (can be configured in the
>>> Device Tree)
>>> b) TX VLAN tag priority configuration (can be configured in the Device Tree)
>>> c) RX VLAN tag priority routing configuration (can be configured in the
>>> Device Tree)
>>> d) TX weight configuration (can be configured in the Device Tree)
>>> e) RX queue to RX DMA channel mapping
>>> f) RX queue enabling
>>> g) MAC and individual queue related interrupt analysis
>>> h) Flow Control configuration by queue
>>>
>>> The number of RX and TX queues to use comes from the FEATURES register.
>>>
>>> With this patch we get the core related operations ready for multiple
>>> queue/channel.
>>>
>>> Signed-off-by: Joao Pinto <jpinto@...opsys.com>
>> 
>> This would be so much easier to review if you used one patch for each
>> of those new configuration features.
>> 
>> In fact, it would make an appropriate complete patch series on it's own.
> 
> Should I put the multiple queues / channels changes in a single patch or should
> I break it into a feature change / patch? What would be easier for you to review?

Submit the first series, and when that is accepted you can do similarly for the
second patch, and then when that's accepted you do the third on in the same
manner.