netdev - Re: [PATCH net-next 0/5] nfp: control processor DMA support and RJ45

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]

Date:   Fri, 01 Mar 2019 12:00:48 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     jakub.kicinski@...ronome.com
Cc:     netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 0/5] nfp: control processor DMA support and
 RJ45

From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Tue, 26 Feb 2019 20:19:28 -0800

> This series starts with adding support for reporting twisted pair
> media type in ethtool.
> 
> Remaining patches add support for using DMA with the control/service
> processor.  Currently we always copy the command data into card's
> memory.  DMA support allows us to have the NSP read the data from
> host memory by itself.  Unfortunately, the FW loading and flashing
> cannot directly map the buffers for DMA because (a) the firmware
> ABI returns const buffers, and (b) the buffers may be vmalloc()ed
> in many mysterious/unmappable way.  So just bite the bullet -
> allocate new host buffer for the command and copy.
> 
> As Dirk explains, the NSP now supports updating all FWs at once
> which means the max flashing time grew significantly.  He bumps
> the max wait to avoid timeouts.

Series applied, thanks Jakub.