linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] fpga zynq: Check the bitstream for validity
Date: Wed, 9 Nov 2016 08:56:51 -0700	[thread overview]
Message-ID: <20161109155651.GA15076@obsidianresearch.com> (raw)
In-Reply-To: <609bc971-bb6d-8cd2-8e64-23c0082a6216@topic.nl>

On Wed, Nov 09, 2016 at 03:21:52PM +0100, Mike Looijmans wrote:
> I think the basic idea behind the commit is flawed to begin with and the
> patch should be discarded completely. The same discussion was done for the
> Xilinx FPGA manager driver, which resulted in the decision that the tooling
> should create a proper file.

That hasn't changed at all, this just produces a clear and obvious
message about what is wrong instead of 'timed out'.

Remember, again, the Xilinx tools do not produce an acceptable
bitstream file by default. You need to do very strange and special
things to get something acceptable to this driver. It is a very easy
mistake to make and hard to track down if you don't already know these
details.

> This driver should either become obsolete or at least move into the
> same direction as the FPGA manager rather than away from that.

I don't understand what you are talking about here, this is a fpga mgr
driver already, and is consistent with the FPGA manger - the auto
detect stuff was removed a while ago and isn't coming back.

It is perfectly reasonable for fpga manager drivers to pre-validate
the proposed bitstream, IMHO all of the drivers should try and do
that step.

Remember, it is deeply unlikely but sending garbage to an FPGA could
damage it.

> Besides political arguments, there's a more pressing technical argument
> against this theck as well: The whole check is pointless since the hardware
> itself already verifies the validity of the stream.

The purpose of the check is not to protect the hardware. The check is
to help the user provide the correct input because the hardware
provides no feedback at all on what is wrong with the input.

And again, the out-of-tree Xilinx driver accepted files that this
driver does not, so having a clear and understandable message is going
to be very important for users.

> doesn't have any effect, the hardware will discard it. There's no reason to
> waste CPU cycles duplicating this check in software.

In the typical success case we are talking about 5 32 bit compares,
which isn't even worth considering.

Jason

  parent reply	other threads:[~2016-11-09 15:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 22:54 [PATCH] fpga zynq: Check the bitstream for validity Jason Gunthorpe
2016-10-27  7:42 ` Michal Simek
2016-10-27 14:32   ` Jason Gunthorpe
2016-10-27  8:50 ` Matthias Brugger
2016-10-27 14:39   ` Jason Gunthorpe
2016-10-28 11:06     ` Matthias Brugger
2016-10-28 15:47       ` Jason Gunthorpe
2016-10-28 16:36         ` Matthias Brugger
2016-10-28 16:55           ` Jason Gunthorpe
2016-10-28 18:23             ` Moritz Fischer
2016-10-28 20:26               ` Jason Gunthorpe
2016-10-28 21:00                 ` Moritz Fischer
2016-10-28 22:05                   ` Jason Gunthorpe
2016-10-29  0:09                     ` Moritz Fischer
2016-10-31 16:23                       ` Jason Gunthorpe
2016-11-01  6:39                         ` Michal Simek
2016-11-01 15:33                           ` Jason Gunthorpe
2016-11-01 17:48                             ` Michal Simek
2016-11-08  0:05                               ` Jason Gunthorpe
2016-11-09 14:21                                 ` Mike Looijmans
2016-11-09 15:18                                   ` Matthias Brugger
2016-11-09 16:00                                     ` Jason Gunthorpe
2016-11-09 15:56                                   ` Jason Gunthorpe [this message]
2016-11-09 17:31                                     ` Mike Looijmans
2016-11-28 18:00                                   ` Jason Gunthorpe
2016-11-08  0:46                       ` Jason Gunthorpe
2016-11-08  9:59                         ` Matthias Brugger
2016-11-08 16:24                           ` Jason Gunthorpe
2016-10-28 11:12 ` Matthias Brugger
2016-10-28 15:48   ` Jason Gunthorpe
2016-10-28 16:37     ` Matthias Brugger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161109155651.GA15076@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).