All of lore.kernel.org
 help / color / mirror / Atom feed
From: moritz.fischer@ettus.com (Moritz Fischer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] fpga zynq: Check the bitstream for validity
Date: Fri, 28 Oct 2016 11:23:08 -0700	[thread overview]
Message-ID: <20161028182308.GB18325@live.com> (raw)
In-Reply-To: <20161028165555.GA17998@obsidianresearch.com>

On Fri, Oct 28, 2016 at 10:55:55AM -0600, Jason Gunthorpe wrote:
> 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.

I'm fine with checking for boundary cases where the bitstreams are
obviously too small or wrong size, I'm not convinced that checking using
internal knowledge about the bistream format inside the kernel is the
right place.

> 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..

I don't know about you, but for my designs I can just use what drops out
of my Vivado build. Are you unhappy with the way we document which
format to use, or that we don't slice off the beginning (that gets
ignored by hardware?).

Thanks for addressing the issues with the length calculations,

Moritz

  reply	other threads:[~2016-10-28 18:23 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 [this message]
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=20161028182308.GB18325@live.com \
    --to=moritz.fischer@ettus.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.