linux-kernel - Re: [PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req

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: <CANk1AXTEg76WxXMqk2mvc7zjjL4H0ouHi1ua7SR9gdRV7G+T5w@mail.gmail.com>
Date:   Thu, 13 Jul 2017 16:08:46 -0500
From:   Alan Tull <atull@...nel.org>
To:     "Li, Yi" <yi1.li@...ux.intel.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, mcgrof@...nel.org,
        wagi@...om.org, David Woodhouse <dwmw2@...radead.org>,
        rafal@...ecki.pl, arend.vanspriel@...adcom.com, rjw@...ysocki.net,
        Moritz Fischer <moritz.fischer@...us.com>, pmladek@...e.com,
        johannes.berg@...el.com, emmanuel.grumbach@...el.com,
        Luca Coelho <luciano.coelho@...el.com>, kvalo@...eaurora.org,
        luto@...nel.org, Takahiro Akashi <takahiro.akashi@...aro.org>,
        dhowells@...hat.com, pjones@...hat.com,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fpga@...r.kernel.org,
        Yves Vandervennet <yves.vandervennet@...ux.intel.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: Re: [PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req_params

On Mon, Jun 26, 2017 at 10:28 AM, Li, Yi <yi1.li@...ux.intel.com> wrote:

Hi Greg,

> hi Greg
>
> On 6/23/2017 10:41 AM, Greg KH wrote:
>>
>> On Fri, Jun 16, 2017 at 05:58:29PM -0500, yi1.li@...ux.intel.com wrote:
>>>
>>> From: Yi Li <yi1.li@...ux.intel.com>
>>>
>>> This adds DRIVER_DATA_REQ_NO_CACHE flag with .req flag under struct
>>> driver_data_req_params. When this flag is set, the driver_data driver
>>> will not cache the firmware during PM cycle, which is expensive.
>>
>>
>> Why is it "expensive"?  What do you mean by this?  Caching was added to
>> help things out, why would you not want it?
>>
>
> Say we have couple drivers (GPU, wifi, FPGA, etc) loading firmwares during
> init, with firmware cache feature on, each time the system going to PM
> suspend, the firmware framework will cache all the firmware files (which
> have been loaded before) from fs to RAM, just in case during PM resume the
> drivers need to re-program firmware. If say FPGA driver does not need to
> re-program firmware to hardware for suspend/resume, it's "expensive/wasted"
> to load those in suspend phase and do not use them. Or I am missing
> something?
>
>>> It will be used by streaming case and other drivers which implement
>>> their own cache thing.
>>
>>
>> Why would a driver implement their own cache?  And what do you mean by
>> "streaming case"?
>
> When the firmware file size is too big to fit into the RAM, we try to
> streaming it (load a page and program the page to the hardware and repeat
> till the end of file). For this case, the firmware was not loaded to RAM as
> a whole piece, there is no point/way to cache it.

Streaming for FPGA programming would mean a FPGA driver could load the
firmware a page at a time and write each page to the FPGA. In most
cases there is no need to keep the FPGA image in memory after
programming is done or even keep the whole image in memory while
programming.

As we're starting to look at larger devices with 100Meg FPGA images,
we want to avoid contiguous buffers. An alternative would be firmware
files loaded to scatter gather tables since Jason Gunthorpe added sg
support to fpga-mgr.

Alan Tull