From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] fpga zynq: Check the bitstream for validity
Date: Fri, 28 Oct 2016 10:55:55 -0600 [thread overview]
Message-ID: <20161028165555.GA17998@obsidianresearch.com> (raw)
In-Reply-To: <5ea0e77e-11c5-b4f7-00a9-9c5425ffac5a@suse.com>
On Fri, Oct 28, 2016 at 06:36:06PM +0200, Matthias Brugger wrote:
> Sure but we are checking here that the bitstream passed to the kernel is
> correct.
The intent to check if it *possible* that the bitstream is
correct. Correct means that DONE will assert after programming. A 4
byte bitstream will never assert DONE.
Arguably the threshold should be larger but we don't know what the
true minimum is.
> + /* All valid bitstreams are multiples of 32 bits */
> + if (!count || (count % 4) != 0)
> + return -EINVAL;
> +
Too clever for my taste.
Aside from this, is the general idea even OK? In my world I cannonize
the bitstream to start with the sync word, but others may not be doing
that.
I designed this patch based on the prior work to remove the
auto-detection, eg that the driver should be passed a canonized
bitstream.
The problem with the way it is now is how hard it is to figure out
what the right bitstream format should be. Clear instructions to
canonize by droping the header before the sync word and byteswap so
the sync word is in the given order is much clearer..
Jason
next prev parent reply other threads:[~2016-10-28 16:55 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 [this message]
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
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=20161028165555.GA17998@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.