linux-kernel - Re: [PATCH v2 2/3] fpga manager: framework core

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2014 13:14:57 +0100
From:	Pavel Machek <pavel@...x.de>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	atull <atull@...nsource.altera.com>,
	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Rob Herring <robh+dt@...nel.org>,
	Ira Snyder <iws@...o.caltech.edu>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>, philip@...ister.org,
	rubini <rubini@...dd.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Jason <jason@...edaemon.net>, kyle.teske@...com,
	Nicolas Pitre <nico@...aro.org>,
	"Balbi, Felipe" <balbi@...com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	David Miller <davem@...emloft.net>, cesarb@...arb.net,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com,
	Yves Vandervennet <yvanderv@...nsource.altera.com>
Subject: Re: [PATCH v2 2/3] fpga manager: framework core

Hi!

> > * this causes the fpga to get programmed
> > * appropriate bridges get enabled
> > * appropriate drivers get probed
> 
> For the case of a fixed function device it's sort of equivalent to a
> firmware load (in fact it *is* just a firmware load). The fixed function
> cases don't actually even need a 'firmware manager' or an FPGA class. In
> fact they shouldn't IMHO have one because the fact version A of the
> device requires firmware bitstream X, and bitstream X is an altera FPGA
> bitstream is an implementation detail. Revision B could be a
> microcontroller or something else and you still just shove a bitstream
> down it. No FPGA class is needed or appropriate. FPGA loader helpers
> yes.

Well, you'd still like to use the FGPA class to talk to the FPGA
loader, because that makes transition to different FPGA vendor easier,
right?

> 1. Fixed function firmware - in which case the driver already handles it
> and we don't care if its FPGA bitstreams or microcode or CPU code or
> whatever
> 
> 2. Dynamic use cases where we need a resource we own, which means
> enumerate/open/close/read/write interfaces including firmware.
> 
> For use case #1 I don't believe we need magic classes for FPGA and in
> fact they are actually a mistake,

Why? Bitstream upload code is fairly complex, and it seems the high
level steps are similar between vendors. Having FPGA class people can
work with helps, and it will help in future more dynamic cases, too...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/