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, 6 Dec 2017 16:28:55 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Alan Tull' <>
CC:     Wu Hao <>, "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Tim Whisonant <>,
        "Enno Luebbers" <>,
        Shiva Rao <>,
        Christopher Rauer <>,
        Xiao Guangrong <>
Subject: RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Alan Tull
> Sent: 06 December 2017 15:30
> On Wed, Dec 6, 2017 at 3:44 AM, David Laight <> wrote:
> > From: Wu Hao
> >> Sent: 06 December 2017 05:30
> > ...
> >> > Regarding file names, it seems like the files added to drivers/fpga
> >> > could be uniformly named dfl-*.[ch].  Some are fpga-dfl-*.[ch] while
> >> > other are currently dfl-*.[ch] currently.
> >
> > They don't even want to do into a drivers/fgpa directory.
> > Maybe drivers/dfl or drivers/dfl/intel
> It's plugged into the fpga framework in drivers/fpga.  This patchset
> also handles reprogramming the fpga, not just the dfl style
> enumeration.  But your points about this being not just for FPGA are
> interesting to me.  Do you have a use for this that isn't
> FPGA-centric?

That all just seems wrong to me.
If you've managed to invent some common code for reprogramming fpga
I'd have though it would be library functions.

The driver ought to sit somewhere related to its functionality.

Our fpga loads from a serial EEPROM, the image is about 6.5MB.
We can rewrite it from userspace by mmap()ing part of one of the BARs
to access some very locally written (by me) VHDL that does most of
the required bit-banging for 32it word accesses.
You really wouldn't want to load 6.5MB into kernel space!

We also had to solve the problem of 9 separate driver modules that
want to access different parts of the BARs.
I think we have 46 separate slaves in the fpgas BARs (most are in 1 BAR).
Some of these are common between different boards (or completely different
memory maps for the same board.

I can imagine some generic method of having a 'board' driver for a
specific PCI-id that knows the BAR offsets of various functions so that
other sub-drivers could be loaded to access those functions.
But that is some kind of pseudo-bus not fpga specific in any way.


Powered by blists - more mailing lists