linux-kernel - Re: [RFC PATCH] fpga: Introduce new fpga subsystem

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]

Date:	Wed, 18 Sep 2013 14:32:47 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, monstr@...str.eu,
	Alan Tull <atull@...era.com>, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stephen Warren <swarren@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	David Brown <davidb@...eaurora.org>,
	Dom Cobley <popcornmix@...il.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem

On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:

> + Jason Gunthorpe

Thanks, looks interesting, we could possibly use this interface if it 
met our needs..
 
> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > This new subsystem should unify all fpga drivers which
> > do the same things. Load configuration data to fpga
> > or another programmable logic through common interface.
> > It doesn't matter if it is MMIO device, gpio bitbanging,
> > etc. connection. The point is to have the same
> > inteface for these drivers.

So, we have many years of in-field experience with this and this API
doesn't really match what we do.

Here are the steps we perform, from userspace:
 - Ask kernel to place FPGA into reset and prepare for programming
   * Kernel can return an error (eg FPGA failed to erase, etc)
   * this is the PROG_N low -> DONE high, PROG_N high -> INIT_N high
     sequencing on Xilinx chips
 - Ask kernel to load a bitstream.
   * Userspace locats the bitstream file to load, and the mmaps it.
   * Userspace passes the entire file in a single write() call to the
     kernel which streams it over the configuration bus
   * The kernel can report an erro rhere (eg Xilinx can report CRC
   error)
 - Ask the kernel to verify that configuration is complete. 
   * On Xilinx this wait for done to go high
 - Ask the kernel to release the configuration bus (tristate
   all drivers) (or sometimes we have to drive the bus low,
   it depends on the bitfile, user space knows what to do)

It is very important that userspace know exactly which step fails
because the resolution is different. We use this in a manufacturing
setting, so failures are expected and need quick root cause
determination.

You could probably address that need by very clearly defining a
variety of errno values for the various cases. However, it would be a
disaster if every driver did something a little different :|

Using request_firmware exclusively is not useful for us. We
format the bitfile with a header that contains our internal tracking
information. Sometimes we need to bitswap the bitfile. Our userspace
handles all of this and can pass a bitfile in memory to write().

request_firmware would be horrible to use :)

Our API uses a binary sysfs attribute to stream the FPGA data, you
might want to consider that.

Regards,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/