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: <20220531022004.2314963-1-tien.sung.ang@intel.com>
Date:   Tue, 31 May 2022 10:20:04 +0800
From:   tien.sung.ang@...el.com
To:     yilun.xu@...el.com
Cc:     dinh.nguyen@...el.com, hao.wu@...el.com,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        mdf@...nel.org, tien.sung.ang@...el.com, trix@...hat.com
Subject: Re: [PATCH] fpga: altera-cvp: allow interrupt to continue next time

>> CFG_READY signal/bit may time-out due to firmware not responding
>> within the given time-out. This time varies due to numerous
>> factors like size of bitstream and others.
>> This time-out error does not impact the result of the CvP
>> previous transactions. The CvP driver shall then, respond with

>Do you mean the reprogramming is successful even if you find the time
>out in write_complete()? Then return 0 is better?
Based on the information given by the Intel FPGA firmware team,
CFG_READY is essential to indicate if the current FPGA 
configuration session is indeed a success. There are 
cases we test in the lab whereby, CFG_READY stays invalid and
the tests performed subsequently to verify the FPGA functionality
could not detect the failed session. A failed FPGA 
configuration session means, the new bitstream wasn't 
successfully configured and tests ran later will just be passing
on the previous working bitstream version. In short, CFG_READY
is esential, and an error indicating the time-out is a must.
Another example, using an incorrect SOF/Design FPGA results
in CFG_READY being invalid. The user must be informed of a 
potential error. 
I will correct the wordings i used earlier that says that
the timoeut error does not impact the results of the CvP
previous transactions. It may so if the firmware has some sort
of error. 

>And could you specify what the time-out mean on write_init() phase?
I could not really understand your question. We set huge 
time-outs of ~10seconds. Every wait for the firmware to respond
is potentially a hazard. The firmware CvP is has it's limitation
unfortunately. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ