linux-kernel - Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

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: <201212012048.51012.arnd@arndb.de>
Date:	Sat, 1 Dec 2012 20:48:50 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Philip Balister <philip@...ister.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Eli Billauer <eli.billauer@...il.com>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@...x.de>,
	John Linn <john.linn@...inx.com>,
	Michal Simek <michal.simek@...inx.com>,
	"Ira W. Snyder" <iws@...o.caltech.edu>,
	Josh Cartwright <josh.cartwright@...com>
Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

On Saturday 01 December 2012, Philip Balister wrote:
> On 11/30/2012 09:36 AM, Greg KH wrote:
> > Yes, I know of at least one more device other than the ones listed above
> > that wants this type of functionality as well, so defining it in a
> > standard user/kernel api manner would be very good to do.
> 
> I'm concerned that a standard driver for FPGA's will be a very difficult 
> problem.
> 
> The Xillybus driver looks interesting on several levels, however my 
> first concern is depends on a FPGA IP block that is not open source. 
> This is not a bad thing, just a potential obstacle for some people.

I agree that is a concern, but for now, I'm mostly worried about
the kernel-to-user interface. If we can agree on a driver interface
that works for Xillybus as well as any of the others we know about,
we can start using that as the generic kernel FPGA interface.

Once we get a second FPGA driver, that can use the same user
interface but talk to the hardware in a different way, and then
we can reorganise the code to keep the user interface bits in a
common driver, away from the hardware specific parts.

If you see anything in the user interface that directly depends on
the Xillybus IP block, then that would make the approach impossible
and we should change that to be more generic.

> I've been engaged in design discussions today with my customer. Our 
> target is the Xilinx Zynq hardware. The first pass at a driver focuses 
> on creating the minimal amount of code in the kernel doing most of the 
> logic in user space. So the driver code allocates a large chunk of RAM 
> for the FPGA to read/write to, provides a mmap function so user space 
> can see this RAM, also mmaps in the address space of an AXI slave so the 
> user space can control the logic. This approach has no dependencies on 
> what is loaded into the fpga.
> 
> This is a very different approach then the Xillybus driver, but should 
> also be useful to a large class of people. Hopefully, we can converge on 
> a set of useful drivers, and not end up with a million drivers all based 
> on custom fpga configuration :)

Agreed. If I understand you correctly though, your approach is specific
to a particular hardware implementation (Zynq) on the user interface layer,
which I think is exactly what we should avoid. Obviously, there is
always a driver involved that is specific to the IP block you load into
an FPGA at runtime, and that is ok. The two parts that I think we
should agree on are:

a) How to get a payload into the FPGA

b) How to find a device driver that can make the payload interface to user
   space.

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