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]

Message-ID: <1380136900.4810.22.camel@atx-linux-37>
Date:	Wed, 25 Sep 2013 14:21:40 -0500
From:	Alan Tull <atull@...era.com>
To:	Michal Simek <monstr@...str.eu>
CC:	Philip Balister <philip@...ister.org>,
	Pavel Machek <pavel@...x.de>, "H. Peter Anvin" <hpa@...or.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Jason Cooper <jason@...edaemon.net>,
	Michal Simek <michal.simek@...inx.com>,
	<linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	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

> > 
> > For the Zynq based product I am working on, we encourage the end user to
> > create their own bitstreams to customize their application. So we need
> > an easy way for the user to load a bitstream. cat foo.bin > /dev/xdevcfg
> > works well for us.
> 
> You probably don't care if this will be
> cat foo.bin > /sys/fpga/fpga0/<whatever>
> (for zynq case you can also run)
> cat foo.bit > /sys/fpga/fpga0/<whatever>
> 
> FYI: Current driver in xilinx repo supports bit format too.
> 

Michal,

So your low level driver has a back door to avoid having to use the
firmware class?  I thought the point of this exercise was to have a
framework with a unified interface.

My original framework supported the interface you mention here.

If we are going to have a framework, we should spec in in such a way
that vendors won't be required to add back doors to their drivers in
order to support the use cases they are interested in.

If the firmware interface isn't going to work all the fpga use cases,
then why upstream this patch?  In that case we should go back to the
original implementation and have a unified interface that supports
cat'ing the bitstreams to /sys instead.

My current opinion about the firmware class is that we can use it (and
it is best to use existing interfaces), but it is not really suited for
all the fpga use cases.

The other thing the original fpga framework had was a transport layer.
The intent was to eventually support the same driver (such as a bitbang
driver) no matter what type of gpio lines it was attached to.  It wasn't
really necessary for the fpga manager that is bolted onto a soc, but it
will be needed if you have an fpga that gets programmed from another
fpga that is connected to a soc.  Otherwise you have to write separate
drivers depending on how the fpga is connected.

Alan

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