linux-kernel - Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

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] [day] [month] [year] [list]

Date:	Sat, 21 Feb 2015 00:31:36 -0600
From:	atull <atull@...nsource.altera.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Ming Lei <ming.lei@...onical.com>,
	Michal Simek <michal.simek@...inx.com>
CC:	Pavel Machek <pavel@...x.de>, Rob Landley <rob@...dley.net>,
	"Pantelis Antoniou" <pantelis.antoniou@...sulko.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<hpa@...or.com>, Michal Simek <monstr@...str.eu>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <robh+dt@...nel.org>,
	Grant Likely <grant.likely@...aro.org>, <iws@...o.caltech.edu>,
	<linux-doc@...r.kernel.org>, Mark Brown <broonie@...nel.org>,
	<philip@...ister.org>, <rubini@...dd.com>,
	"Steffen Trumtrar" <s.trumtrar@...gutronix.de>,
	<jason@...edaemon.net>, <kyle.teske@...com>, <nico@...aro.org>,
	Felipe Balbi <balbi@...com>, <m.chehab@...sung.com>,
	<davidb@...eaurora.org>, <davem@...emloft.net>,
	<cesarb@...arb.net>, <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Walleij <linus.walleij@...aro.org>, <pawel.moll@....com>,
	<mark.rutland@....com>, <ijc+devicetree@...lion.org.uk>,
	<galak@...eaurora.org>, <devel@...verdev.osuosl.org>,
	Alan Tull <delicious.quinoa@...il.com>,
	<dinguyen@...nsource.altera.com>, <yvanderv@...nsource.altera.com>
Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

On Thu, 19 Feb 2015, Michal Simek wrote:

> On 02/17/2015 08:17 PM, Pavel Machek wrote:
> > On Tue 2015-02-17 11:07:53, Rob Landley wrote:
> >>
> >>
> >> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> >>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> >>>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> >>>> My point is that the current firmware layer is overly cautious and
> >>>> FPGAs are very big. My current project on small Xilinx device has a
> >>>> 10MB programming file. The biggest Xilinx device today has a max
> >>>> bitfile size around 122MB.
> >>>>
> >>>> So keeping that much memory pinned in the kernel when I can prove it
> >>>> is uncessary for my system (either because there is no suspend/resume
> >>>> possibility, or because I know the CPU can always access the
> >>>> filesytem) is very undesirable.
> >>>
> >>> Well, your current device aalso has 1GB RAM, no?
> >>
> >> Unnecessarily pinning 10% of your ram is a good solution?
> > 
> > Never said that. But I'd rather have _some_ API proposed, then try to
> > design in everthing including kitchen sink and do nothing.
> 

I propose an extension to the firmware class:

int request_firmware_streamed(const struct firmware **firmware_p,
                              const char *name,
                              struct device *device,
                              int (*consumer)(char *buf,
                                              size_t size,
                                              void *priv))

This is a new function that streams the firmware file in 4k chunks to
a callback function.  So firmware is not limited to the allocation
size of vmalloc.

This new function would have the same parameters as request_firmware except
adding a pointer to a consumer function.  In the case of fpga's, the
consumer function is writing the 4k chunks to the fpga.

The new function will:
 * open the file
 * read 4k
 * hand that buffer to the consumer
 * sleep until the consumer returns
 * give up if consumer has a nonzero exit, continue reading otherwise

Admittedly this is really different from the current firmeware class's
structures.

The real problem this is trying to solve is that bitstreams can be huge,
especially as fpga's can be daisychained.  And the CPU doing the loading
could be embedded (limited resources).  IFAIK fpga's don't need to have
the whole image in a ram buffer.

This gives us the convenience of request_firmware() and gives the kernel an
extension of the firmware class that others might useful instead of solving
this problem that we keep hovering around for fpga's only.

Alan Tull

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